nicht angemeldet
Hi!
Bei Java ist es ein Standard, mit definiert benannten Gettern und Settern zu arbeiten, da einige Bibliotheken auf diese Konventionen abgestimmt sind. Für PHP gibt es einen derartigen übergreifenden Standard nicht.
Wobei in Frameworks wie Zend doch damit auf die Eigenschaften einer Klasse zugegriffen wird. Somit ist klar, dass für alles, was gegetted und gesetted werden kann, eine Methode dafür da sein sollte. Somit sieht man an den gettern und settern, was die Klasse kann und welche Konfigurationen sie zulässt.
Ich sehe auch, wenn eine les- und schreibbare Eigenschaft public ist, dass man darauf zugreifen darf. Dazu brauch ich vom Prinzip her keinen Getter/Setter. Sollte dein zweiter Satz sowas wie eine Gesetzmäßigkeit beschreiben? Wenn ja, so kann ich dem nicht zustimmen. Das ZF ist keine Instanz, die Coding-Standards verbindlich oder auch nur durch die Macht des Faktischen festlegen kann.
Am besten von den mir bekannten Sprachen finde ich das bei C# gelöst. Da gibt es Propertys, die wie öffentliche Objektvariablen angesprochen werden. Getter und Setter werden direkt der Property hinzugefügt und sind nach außen hin nicht sichtbar. Wenn man bisher eine öffentliche Objektvariable hatte und nun eine komplexere Zugriffslogik haben möchte, schreibt man diese Variable in eine Property um und muss keinen Code ändern, der darauf zugegriffen hat.
Deklaration einer Objektvariablen:
public string Foo;
Zugriff darauf:
instanz.Foo = ...
Deklaration einer Property:
public string Foo {
get {...}
set {...}
}
Zugriff darauf:
instanz.Foo = ...
Wenn ein Getter oder Setter nichts weiter macht, als auf eine private Variable zuzugreifen, so kann man sich auch das explizite Deklarieren dieser privaten Variable sparen und die Property als Einzeiler anlegen.
public string Foo { get; set; }
Auch öffentlich nur lesbare Propertys kann man mit der Kurzform anlegen.
public string Foo { get; private set; }
Nunja, PHPs OOP ist eine nette Dreingabe, die man nicht mit von anderen Systemen bekannten Vorgehensweisen überstrapazieren sollte.
Über eine Liste von Eigenschaften, zB. eines "Besuchers", möchte man dann vielleicht iterieren. Insofern bietet sich als Rückgabewert ein assoziatives Array oder eben Object an. Eeine Klassen-Methode wie "getModules" wird sowas wohl liefern, oder besser ein einfaches Array.
In der Vergangenheit wollte ich selten über alle Eigenschaften eines Objekts iterieren. Das kommt vielleicht vor, wenn das Objekt in Gänze persistiert werden soll, oder wenn man eine selbst formatierte Kontrollausgabe erzeugen will. Was besser ist oder nicht hängt vom konkreten Einsatzfall ab. Das kann ein Array sein, das kann ein Objekt sein, das kann aber auch ein Iterator aus der SPL sein. Beim Objekt hast du aber wieder das Problem, wenn du strikt Coding-Style-kompatibel zum ZF sein willst, dass du dann Getter und Setter schreiben solltest und mit diesen keine Typkonvertierung nach array vornehmen kannst. Im Allgemeinen halte ich es aber für programmiertechnischen Unsinn, wenn eine Klasse, die Eigenschaften und Methoden zu einem bestimmten Thema bereitstellt, ein Objekt oder Array liefert, das nichts weiter als die reinen Daten ihrer selbst beinhaltet. Dann schon lieber einen Iterator oder ähnliches, aber eingebettetes Konstrukt.
Lo!