nicht angemeldet
hi,
Wenn es die Übersichtlichkeit/Wartbarkeit des Codes erhöht, würde ich einen solch geringen Performance-Verlust in jedem Fall in Kauf nehmen. Allerdings gebe ich zu, dass man über die Frage, ob durch den Einsatz von Gettern/Settern tatsächlich die Übersichtlichkeit erhöht wird, sicher vortrefflich streiten kann.
Ja ;)
Hier eine meiner Ideen:
- Ein Argument => Methode ist ein Getter
- Zwei Argumente => Methode ist ein Setter
Methode 'eav': Entity (Response), Attribute, Value
// $this ist die Instanz der Controller-Klasse (Response Class in meinem FW)
$this->eav('title'); // gib mir mal den Titel
$this->eav('title', 'Neuer Titel für die Seite'); // geht zur Laufzeit
$this->eav('title', $this->eav('title')." Anhängsel"); // geht auch
In Java ist es eine Konvention mangels besserer Möglichkeiten dieser Sprache. Es gibt einige Frameworks/whatever, die auf die Benennung get.../set... reagieren oder anderweitig darauf angewiesen sind, um richtig zu funktionieren. Diese Notwendigkeit ist mir von PHP her nicht bekannt.
Zuviel Voodo ;) Ein Kollege sagte mal: Einen Getter/Setter würde ich niemals einen Namen geben, der mit get/set anfängt...
Naja, Symfony2 nutzt z.b. diese Mechanismen sehr exzessiv (sowohl in der Datenbankschicht, also der "Doctrine"-Welt, als auch bei der Template-Engine Twig). Ich mag mich täuschen, aber ich glaube bei Zend gibt es auch solche Konventionen.
...dabei ging es um Magento (Zend).
Ich finde, jeder darf die Magic-Methods sooo mißbrauchen, wie er das für gut befindet. PHP __call() missbrauche ich z.B. für Methoden, die aufgrund ihrer Zeilenzahl die Code-Struktur einer Controller-Klasse optisch versauen würden: Ab damit ins Dateisystem ;)
Hotti