nicht angemeldet
Hallo,
Statt einer Zuweisung (mit Nebenhandlungen wie Variablennamenauflösung) hast du zwei Zuweisungen und einen Funktionsaufruf. Beim Lesen ungefähr daselbe.
Ok, Ack
Der Zeitverbrauch mag bei kleinen Projekten keine Rolle spielen, aber bei vielen Zugriffen läppert sich das ganz schön zusammen.
Ich wage zu bezweifeln, dass so etwas tatsächlich ernsthaft ins Gewicht fällt.
Ich habe es bisher noch bei keiner PHP-Anwendung erlebt, dass der Bottlenck tatsächlich CPU-Zeit war - wenn ich eine Anwendung fixen/optimieren musste, die performancemässig im Keller war, war so gut wie immer ein lausiges Datenbank-Design, nicht-optimierte SQL-Statements, unnötige IO, zu viel Arbeitsspeicher-Verbrauch uvm. schuld.
Der Performance-Gewinn, der durch Caching, clevere Datenbankschichten, Vermeidung unnötiger IO uvm. möglich ist, ist um Welten größer als das, was man durch die Einsparung des Overheads an CPU-Zyklen spart.
Es mag sein, dass auf embedded Systemen o.ä., wo man wirklich mit begrenzten Resourcen auskommen muss oder bei sehr rechenintensiven Prozessen tatsächlich Probleme bekommt. In diesem Fall ist PHP aber vermutlich eh nicht Mittel der Wahl als Programmiersprache.
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.
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.
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.