Rolf B: Getter / Setter vs. Eigenschaften im Konstruktor

Beitrag lesen

Hallo ebody,

es kommt darauf an, ob die Eigenschaften deines Objekts readonly sein sollen oder nicht.

Für readonly-Eigenschaften reichen eine Festlegung im Konstruktor und öffentliche Getter.

Wenn die Eigenschaften von außen auch verändert werden können sollen, brauchst Du auch einen Setter.

Nach der reinen Lehre solltest Du aber auch im Konstruktor die Setter verwenden.

Solange Du im Setter nur eine private Eigenschaft setzt, scheint er ziemlich zwecklos. Aber Du kannst dort auch prüfen, ob der gesetzte Wert zulässig ist. Du hast ggf. Eigenschaften, deren Veränderung weitere Auswirkungen hat. Einfaches Beispiel: Ein Objekt "Kreis" mit den Eigenschaften "radius" und "fläche". Ändert man den Radius, muss sich auch die Fläche ändern. Natürlich kann man die Fläche bei jeder Abfrage neu aus dem Radius berechnen. Das kostet aber bei vielen Flächenabrufen mehr Laufzeit und es ist effizienter, sie im Setter des Radius zu aktualisieren. Das Beispiel ist natürlich konstruiert, der Nutzen ist minimal.

Ein anderes Beispiel ist ein Objekt des Datenmodells. Das Objekt wurde aus der Datenbank geladen und hat so etwa drölfzig fachliche Eigenschaften, von denen ein Anwender etliche verändern kann. Wenn Du nun $repository->save($object) aufrufst - woher weiß das Repository nun, welche Eigenschaften geändert sind? Soll es die alte Version vorhalten und Stück für Stück die Eigenschaften vergleichen? Oder wäre es einfacher, wenn die Setter dieser Eigenschaften die Änderung tracken und sich das Update SQL daraus automatisch ergibt?

Rolf

--
sumpsi - posui - obstruxi