PHP Blogger

Startseite Schreib mir ne Mail! RSS Abo Webnews

Sei ein Objekt-Schwein!

Du stehst auf Objektorientierung? Du versuchst alles und jeden in ein Objekt zu verpacken und wild hin und her zu vererben? Dann gibst Du genau der oder die Richtige, wenn es darum geht, genau das nicht zu machen :)

Ich will, das Du mit mir die Regeln brichst. In den Sonnenuntergang reitest und auf alle Objekte und Klassen der Welt pfeifst… Es geht nämlich um Hilfsfunktionen und wie man sie am besten in Dateien und verpackt und included.

Überlegen wir erst mal, wie man Hilfsfunktionen ablegen könnte:

  • Globale Funktionen
  • Klassenmember Funktionen
  • Statische Klassenmember Funktionen

Gucken wir uns mal die konkrete Aufruf-Implementierung mit hilfe eines imaginären String-Objektes an:

Globale Funktionen:

$erg= string_replace($altstr, $neustr, $quellstr);

Klassenmember Funktionen:

$str= new StringObjekt($quellstr);
$erg= $str->replace($altstr, $neustr);

Statische Klassenmember Funktionen:

$erg= StringObjekt::replace($altstr, $neustr, $quellstr);

Die Möglichkeiten sind alle gültig und denkbar. Welche gefallen besonders? Ich würde sagen, die globale und die statische Variante. Die globale eher die herkömmliche Methode im PHP Sinne, die statische Variante eher schick in Bezug auf die Objektorientierung.

Da Standard-Klassenmember-Funktion benötigt ein Objekt (und damit eine Initialisierung), um zu funktionieren und ist daher eher umständlich zu benutzen.

Wenn beide Funktionen ästhetisch zu benutzen sind, gibts einen Vorteil für die eine oder andere Funktionsvariante? Ja, die globale Funktion ist schneller. Ganz klar - für die statische Funktion muss eine Klasse vom PHP Interpreter interpretiert werden - für die globale nicht.

Was das Beispiel zeigen soll ist vielleicht klar - Nicht immer ist die vollgeladene Objektorientierung die beste Wahl, wenn man performante Applikationen herstellen möchte. Man darf nie vergessen, PHP wird interpretiert - und alles was an Strukturen mehr interpretiert werden muss, als unbedingt notwendig, frisst Performance.

Also! Brich die OOP-Regeln und wälz Dich mal wieder so richtig im prozeduralen Schlamm!

Manuel Grundner meint dazu:

12. Juni 2009 um 14:46

Ich kann dir in diesem Bezug nur teilweise zustimmen.
Klar Performancetechnisch hast du vollkommen recht, aber auf dieser Ebene Performance zu optimieren halte ich für etwas fehl am Platz.
Die statischen Klassen haben den Vorteil das man ähnliche Methoden kapseln kann, und zentral wartbar zu machen, und bei Bedarf durch eine schnellere Variante austauschen.
Der Entwickler der die Methode benutzen muss kann sich dann auch drauf verlassen das er z.B. String-Methoden in der abstrakten (statischen) Klasse StringHelper findet.

Das erhöht die Wartbarkeit schon entscheidend. Und wenn der Code wartbarer ist, bleibt mehr Zeit für echte Performanceoptimierung… Cachen, Cachen, Cachen… und Datenbankabfragen zu optimieren.

Mithilfe von Namespaces könnte man jedoch wieder zu Funktionen wechseln.. Aber da gibts wieder kein Autoloading…

Lieben Gruß
Manuel

Ps.: Die Kritik ist freundlicher Natur :)

RSS für Kommentare zu diesem Artikel · TrackBack URI

Schreib Deine Meinung