nicht angemeldet
Hi!
So ist es aber, abseits aller Pattern, die sich im Lauf der Zeit dazuentwickelten, gedacht gewesen, dass es Datensatz und Verwalter in einem ist. Sonst hätte man gleich bei der Trennung nach Daten und Funktionen bleiben können.
Naja, kann es ja sein, dennoch hast du doch recht schnell auch Daten unterschiedlichen Typs, zB. Systemvariablen (Gruppenzugehörigkeit, ID, Verlaufsdaten etc.) und vielleicht auch vom Nutzer konfigurierbare Daten. Für eine Datensammlung wäre dann ein Array eher sinnvoll, oder könnte es sein.
Ich sehe nicht, worauf du hinauswillst. Die Strukturierung der Objekte nach Zuständigkeiten ist ein architekturelles Problem eines bestimmten Anwendungsfalles. Das Separierieren nach Aufgaben ist eine wichtige Design-Entscheidungsfrage, aber je nach Fall können verschiedene Dinge alles eine Soße sein und ein anderes Mal muss man sie noch in sich aufteilen. Das hat aber wenig damit zu tun, dass man nach der grundlegenden OOP-Philosophie Daten und deren Methoden in ein Gebilde zusammenfassen soll.
Es ging mir [...] um einen etwas reduzierteren Aufwand, dass man bei der Anwendung nicht nach getBar() und setBar() trennen muss sondern einfach nur Bar() für beides benutzen kann.
Naja, aber versteckst du dann nicht die Bezeichnung oder was die Funktion kann im Namen. Und sollte nicht immer jede Funktion nur eine Sache können? Ist vielleicht auch vom Bedarfsfall und Geschmack abhhängig.
Wie gesagt, ich finde ja schon das übertriebene Trennen in Lese- und Schreib-Vorgang unsinnig. Noch schlimmer wird es meiner Meinung nach, wenn beispielsweise wegen einer alphabetischen Sortierung ein Getter nicht mehr in unmittelbarer Nachbarschaft zum Setter im Quellcode notiert ist. Das erschwert die Erfassung der Sinn-Zusammenhänge noch mehr, und das bei sowieso schon aufgeblähtem Code. Wenn man da keine IDE mit einklappbaren Codeteilen hat ...
new Product("Autor","Titel","Preis","Shortdesc","Ustklasse","basename","ISBN") aber zB. macht aus meiner Sicht nicht allzuviel Sinn oder nicht unbedingt.
Eher $Producthandler::getInstance()->addProduct(array("autor"=>"Hans","title="Titel1" etc.pp.));
Der kann dann dem Produkte gleich noch zusätzlich eine interne ID verpassen, ein Einstellungsdatum, vielleicht auch wer es eingepflegt hat etc.pp., also Systemdaten oder Metadaten hinzufügt.
Warum soll man das in einem Konstruktor nicht machen können/dürfen? Der ist für die Initialisierung der Eigenschaften eines Objekts zuständig.
Lo!