Statische Methoden sind einfach nur Funktionen - also Vorsicht!
Da, ich hab's gesagt. So dahin geklatscht wie es wirkt, so simpel ist es auch. String::format() und string_format() ist genau das Gleiche. Der einzige Vorteil den die statische Methode mitbringt, ist, dass durch die Klasse eine Art Namensraum (oder Tag) gegeben ist.
Aber im Endeffekt behaupte ich: Statische Methoden leiten uns dazu, uns von OOP abzuwenden und zurück zu unseren prozeduralen Wurzeln zu gehen. Oder anders gesagt: Faul zu sein.
Bevor ihr mich jetzt würgt, möchte ich anmerken, dass statische Methoden (und Variablen) natürlich ihre Daseinsberechtigung haben. Und man muss sie auch nicht um jeden Preis vermeiden. Doch sollten eure Klassen nur so vom static-Schlüsselwort durchzogen sein, ja dann sollte ihr nochmals die Architektur eurer Applikation überprüfen.
Als Daumenregel postuliere ich:
Statische Methoden sind immer nur dann okay, wenn sie sich auch wirklich wie Funktionen verhalten. Dazu müssen sie zustandloslos sein (selbe Eingabe = selbe Ausgabe, keine Nebenwirkung, etc.). Bei jeder anderen Anwendung ist Vorsicht geboten.
Nachfolgend ein paar wild durchmixte Szenarien, wo wir auf statische Methoden und Variablen treffen.
Ihr wollt Daten global verfügbar machen? Nutzt Objekte und schiebt diese umher. Sowas wie Dependency Injection hilft euch dabei. Globale Daten sind mühsam zu testen und der Code wird unübersichtlich. Ausserdem fällt man mit der Aussage "Aber ich brauche XY nur einmal in meiner App" früher oder später auf die Schnauze. Nutzt keine Registry für die Konfigurationen.
Ihr braucht statische Methoden als Helper? Das ist wohl okay. Aber bedenkt, dass sich konkrete Implementierung einfacher vererben lassen. Auch könntet ihr anstatt
BlogHelper::formatUserName($user)das Strategy Pattern anwenden:$user->formatName(new BlogUserNameFormatter());. Vielleicht gibt's ja dann auch mal eineRssFeedUserNameFormatter-Strategie. Oder eine Strategie dieBlogUserNameFormattererweitert.Ihr braucht eine Factory? Keine Einwände. Factory-Methoden liefern von Natur aus die selben Resultate für gleiche Eingaben. D.h. die Abhängigkeiten müssen meist direkt geliefert werden. Ansonsten findet keine Produktion statt (höhöhö).
Ihr wollt eine API (für andere) entwickeln? Bitte verzichtet auf statische Methoden. Konkrete Implementierungen lassen sich so viel besser erweitern. Ihr könnt anderen viel Frust ersparen.
Um noch auf ein paar Probleme einzugehen:
Vererbung: Das Problem ist nicht die Implementierung der ableitenden Klasse, sondern deren Einsatz. Da überall in eurem Code bei den statischen Methodenaufrufen der Klassenname teil des Aufrufes ist, müsste ihr euren ganzen Code durchsuchen und Anpassungen vornehmen.
Mischmasch: Gerade wenn ihr statische Methoden vor allem für Helper/Util-Klassen nutzt, werdet ihr ziemlich schnell das Single Responsibility Prinzip verletzen. Das besagt nämlich, dass jede Klasse nur eine klare Aufgabe haben sollte und alle Methoden auch nur der Erfüllung dieser Aufgabe dienen sollten.
Ergänzungen? Korrekturen? :)
Ähnliche Artikel
- *knock, knock* - Wer ist da? - PHP 5.4!!111!!eins!!
- Der gelegentlich nützliche Ratschlag von Demeter
- Properties: Neue Get-/Set-Syntax für PHP?
