nicht angemeldet
Moin!
Singleton kommt aus Multithreading und ist in PHP daher kein echter Singleton nach dem ursprünglichen Sinn - sollte deshalb in PHP nicht verwendet werden
Zu einem anderen Aspekt der obigen Aussage moechte ich nur folgendes sagen: Es gibt etliche andere Programmierkonzepte, die in PHP nicht 1:1 so sind, wie sie urspruenglich waren - das Argument, dass das in PHP anders ist, ist aber noch LANGE kein Grund, es in PHP nicht einzusetzen. Das Kriterium sollte doch letztendlich sein: Womit kann ich den besten, simpelsten, effizientesten, wartbarsten, etc. Code schreiben an dieser Stelle? Und _das_ sollte man einsetzen - und nicht eben auf Grund irgend einer puristischen Ideologie suboptimalen Code schreiben.
Singletons sind böse, gerade weil sie ein angehübschter Container für globalen Zustand sind. Man kann damit arbeiten, klar. Globale Variablen zerstören ja auch nicht instant das bekannte Universum. Aber sie haben eben den Nachteil, dass sie extrem schlecht testbar sind, und dass sie in der Regel irgendeinen eher obskuren globalen Zustand enthalten, den man nicht auf den ersten Blick erkennen kann. Und der sich, wenn irgendwas anderes, was auf diesen globalen Zustand auch Einfluss genommen hat, plötzlich wegfällt, vollkommen unerwartet verändern kann.
Deshalb: Hände weg von Singletons, sie fördern undurchsichtige, schwer testbare Programmstrukturen.
Und obendrein, das ist natürlich auch richtig, kann PHP gar keine wirklich ultra-globalen Singletons liefern, jegliches Singleton ist immer nur im Rahmen der einen gerade laufenden Skript-Instanz einzigartig - parallele Requests erzeugen in parallelen Skript-Instanzen immer parallele Instanzen des Singletons.
Abstrakte Methoden und Klassen sollten nicht verwendet werden
Wenn dieser "Experte" keine Begruendung dafuer geliefert hat, kannst Du das getrost ignorieren. Zwar braucht man meiner persoenlichen Erfahrung nach abstrakte Methoden und Klassen in PHP sehr selten (weil man das oft durch Interfaces besser machen kann), aber das heisst nicht, dass sie nicht grundsaetzlich nuetzlich sind. Und es ist garantiert nichts verwerfliches dabei, die zu verwenden.
Interfaces sind nett, wenn man für seine zu implementierenden Klassen vorschreiben will, welche Methoden zu implementieren sind, aber nicht, mit welchem Code das zu geschehen hat.
Abstrakte Klassen eignen sich ganz hervorragend dann, wenn man seinen zu implementierenden Klassen obendrein noch eine gemeinsame nutzbare Codebasis mit an die Hand geben will, und lediglich einzelne Methoden individuell implementiert werden sollen.
Beide Arbeitsweisen gehören für mich absolut zum Handwerkszeug vernünftiger OOP. Insofern ist diese Aussage ohne Begründung nicht viel wert. Und selbst mit Begründung hätte ich Zweifel, ob ich der Meinung zustimmen könnte.
- Sven Rautenberg