[Waq]

Zu share-nothing:
Bei der Parallelisierung, die nunmal nötig ist, um eine Applikation auf mehrere Server oder so zu verteilen, hat man immer das Problem der Komunikation zwischen den Threads. Aus der Java-Welt kennt man hier die komplizierten Alleskönner-Architekturen, die durchaus skalieren, aber nur begrenzt, weil es irgendeinen Knotenpunkt gibt, durch den alles durchmuss.

Bei klassischen PHP-Architekturen wird nichts geteilt, jedes abgearbeite HTTP-Request ist unabhängig. Eigener Apache-Prozess, eigene Session, keine Kommunikation mit den anderen. Keine Zugriffe auf fremde Sessions. Das skaliert endlos in die Breite. Stell zehnmal soviele Server hin und es ist zehnmal so schnell.

http://www.sitepoint.com/blogs/2004/...oesnt-get-php/


Von Singletons halte ich im Allgemeinen eher wenig. Sind schliesslich nichts weiter als globale Variablen, die sich ein OOP-Kleidchen angezogen haben.
Singletons kann man als Abkürzung verwenden, wenn man zu faul ist, Kontexte explizit durchzureichen. Das kann sogar sinnvoll sein, wenn man spezialisierte Architekturen schreibt, die einen Kontext annehmen (z.B. das PHP-Typische "ich bin vom Browser aufgerufen worden und in $_REQUEST stehen meine Daten"), da dass explizite durchreichen von Kontexten durchaus lästig sein kann. Mit wiederverwendbarem OOP hat das allerdings nichts zu tun.

Es gibt keine Objekte, die es nur einmal geben darf. Sowas basiert immer auf einer Annahme, von der nicht zu garantieren ist, dass sie überall gilt, und man vergisst dabei gerne gegen Interfaces statt gegen Implementationen zu programmieren.

Klassisches Beispiel ist der PC-Speaker (das Piep-Ding Ein PC hat immer nur einen PC-Speaker also sollte man dafür ein Singleton verwenden.
Klingt einleuchtend, ist aber Unsinn.
Niemand (ausser dem Betriebssystem usw.) sollte einfach annehmen, dass es einen PC-Speaker gibt. Man sollte annehmen, dass man ein Soundausgabegerät braucht, ein solches als Parameter akzeptieren und darauf den Sound ausgeben. Ob der Sound auf den PC-Speaker geht, auf eine der potentiell mehreren Soundkarten oder obs quer durchs Internet geschickt wird an den Kerl der lieber von Zuhause arbeiten möchte, hat mich an der Stelle nicht zu interessieren.

[Basti]

Zitat von pago

Zum einen wäre es damit notwendig, alle Singletons als Parameter an anderen Klassen/Funktionen zu übergeben, weil man nie wissen kann, ob nach ner Änderungen weiter unten in der Hierarchie nicht doch die Instanz benötigt wird, zum anderen ist der Aufruf einer getInstance-Methode mit Sicherheit nicht in einem relevanten Rahmen aufwendig.

Ich finde das mitunter auch sehr anstrengend, Komponenten "so dumm wie möglich" zu halten. Aber ich glaube dennoch, dass sich der Weg lohnt, wirklich klar zu definieren, wer was weiß und worauf Zugriff hat. Ätzend, wenn man irgendwann merkt, dass die oder die Komponente jetzt aber doch Zugriff auf irgend was braucht, worauf sie eben noch keinen hat und man ev. alle Komponenten diesen Typs nochmal umbauen darf.

Aber die Alternative ist doch ein böses Durcheinander, in dem du selbst aus dem Template (schreibend) auf die Datenbank zugreifen kannst etc. Und wenn ich mich recht erinnere, waren diese Zeiten noch ätzender! Klar, alles geht schön flott on der Hand, aber testen? Und mögliche Fehlerquellen verstreuen sich über die komplette Anwendung.

Sind natürlich extreme, aber die Frage ist ja immer auch, warum man nicht weiß, welche Komponente welche Zugriffe braucht. Ich glaube, in diese Fragen (wer weiß und darf was) zu investieren bringt einen zu den Kernpunkten einer Anwendung. Und wenn man diese sauber geöst bekommt, dann passts (bis zu den nächsten Fragen... *g) und dann braucht man keine Globals und Singletons.

Wenn es von einem Objekt nur eine Instanz geben soll und darf, dann hat das nunmal ein Singleton zu sein. Andernfalls kommst du in Teufels Küche, weil du dann n Objekte mit unterschiedlichem State haben könntest, weil du ab und an mal ne neue Instanz erzeugt hast (warum auch nicht? verbietet dir ja niemand durch nen private Konstruktor und wenn doch ist es ja wieder ein Singleton...).

Hier reicht es, im Kostruktor einen statischen Flag zu setzen und __clone() dicht zu machen (im Extremfall noch in jeder öffentlichen Methode sicherstellen, dass $this existiert).

In der Kritik ist ja nicht, dass man verhindert, dass ein Objekt nochmal gebaut wird, sondern, dass man von überall drauf zugreifen kann. (Bezeihungsweise: Bei "Waq" ist das doch in der "Kritik" - aber es gibt natürlich Konstrukte, die sich nur sehr aufwändig - sei es in der Implementerung oder in der Last zur Laufzeit - realisieren lassen, wenn man nicht ausschließt, dass es maximal eine Instanz von dieser Klasse zur Laufzeit gibt.).

Basti

[Byrel]

@Ben

Ich habe keine Benchmarks durchgeführt, aber rein theoretisch ist ein Singleton langsamer, als wenn du Objekte durchreichst.

Bei einem Singleton rufst du jedesmal eine Funktion auf und das ist wesentlich langsamer als wenn du einfach auf eine Variable zugreifst.

Teste das z.B. mal mit PHP_VERSION und phpversion () aus. Du wirst sehen, dass PHP_VERSION schneller ist.

Ich verwende bei kleineren Sachen (und ich habe hauptsächlich kleine Sachen mit vlt. 200 Besucher pro Tag) aber trotzdem Singletons. Allerdings sollte man sich beim Thema Performance zuerst um andere Sachen kümmern (Apache, Dateisystem, Datenbank, Caching mit 404 ...)

MfG Byrel


[EDIT by Ben]
Diskussion über die Caching-Methode über den HTTP-Code 404: http://forum.developers-guide.net/showthread.php?t=4911

[Ben]

Also das Zend Framework verwendet ja eine Registry, um Singleton-Objekte zu verwalten.

The registry is a mechanism for providing singleton instances of values to the application space. By storing the value in the registry once, and then retrieving the value from the registry whenever it is needed, the same instance is always returned.

http://framework.zend.com/manual/en/zend.register.html

Hm, ich will jetzt nicht sagen "wenn die das machen, dann wird das schon okay sein", aber wenn es wirklich signifikant langsamer wäre, dann würde das in solch einem Framework doch sicherlich auch anders geregelt werden, oder?

Ich muss jetzt auch nicht jede 10000stel Sekunde rauskitzeln .. mir ging es mehr um signifikante Unterschiede.

@bzgl: http_load .. hab ich noch nicht ausprobiert!

[WarrenFaith]

Ich verstehe jetzt nicht so genau den Vorteil der ZF-Variante. Es ist doch egal ob ich eine statische Methode aufrufe oder das über die Registry des ZF mache. Ich denke zweiteres ist sogar noch langsamer oder?

[robo47]

Zitat von WarrenFaith

Ich verstehe jetzt nicht so genau den Vorteil der ZF-Variante. Es ist doch egal ob ich eine statische Methode aufrufe oder das über die Registry des ZF mache. Ich denke zweiteres ist sogar noch langsamer oder?

aber vieleicht hat man so bissel mehr "system" dadrin unter anderem, weil man eine klasse nicht als singleton programmieren muss sondern so einfach zugriff auf EINE Instanz der klasse hat.

[WarrenFaith]

Ist doch Sinn des Singletons nur eine Instanz zu haben!
Wenn ich die Instanz der Configuration einheitlich $Configuration nenne, dann ist das doch kein Problem.
Genauso einfach gehts auch mit $registry->get('Configuration') (bin mir mit dem call jetzt unsicher).
Aber letzten Endes ist das die Implementation von schon vorhandener Funktionalität.

[Ben]

Im Zend Framework existiert genau eine Instanz der Registry. Es können aber jederzeit weitere Zend_Config-Instanzen erstellt werden. Die Registry bietet ja nur den globalen Zugriff auf die Instanzen ...

Keine Ahnung, wo da Vor- und Nachteile liegen.
Habe hier zwar viel gelesen und auch Einiges verstanden, aber so wirklich durchblicken tue ich immer noch nicht.
Aber das kommt ...

[Basti]

Registry und Singleton sind zwei unterschiedliche Patterns. Gemeinsam haben sie, dass sie Objekten einen Zugang zu anderen Objekten (bzw. sich selbst im Falle von Singletons) anbieten, die sonst keinen Zugang hätten, da ihnen nichts übergeben wurde, dass ihnen diesen Zugang geben kann.

Hier allerdings ist das Singleton absolut global und die Registry ist nur den Objekten verfügbar, denen sie auch übergeben wurde (falls sie nicht selbst als Singleton oder statische Klasse implementiert ist).

Der wichtige Unterschied aber ist, dass es von einer Singleton-Klasse nur eine Instanz geben kann, eine Registry kann aber Instanzen von Klassen aufnehmen, die noch weitere Instanzen im Umlauf haben.

Ich habe auch die Reistry aus meinem Framework/CMS rausgeschmissen, macht manches aber nicht einfacher bzw. ich hab noch nicht überall einen passenden Ersatz gefunden.

Basti

[Byrel]

Hm, ich will jetzt nicht sagen "wenn die das machen, dann wird das schon okay sein", aber wenn es wirklich signifikant langsamer wäre, dann würde das in solch einem Framework doch sicherlich auch anders geregelt werden, oder?

Ehrlich gesagt. Wenn deine App. ne perfekte Performance hinlegen soll, dann sollte das Zend Framework IMHO vermieden werden. Ich weiß zwar nicht ob das noch immer so ist, aber als ich mich mit dem Framework 0.1.X beschäftigt habe, war der Code nur voll von Sachen wie "if (substr () === "text")", require_once, magic methods, Funktionsaufrufe in Schleifen, capturing regexp ... .

MfG Byrel

[Ben]

Zunächst einmal gibt es imho die "perfekte Performance" nicht und außerdem geht es ja eher um einen Kompromiss. Die Frage ist einfach, auf welche Engpässe man aufpassen muss, im konkreten Fall eben, ob Singletons solch einen Engpass darstellen könn(t)en.

Ich habe den Thread ja nicht in Zusammenhang mit der Nutzung des ZF erstellt.

Und nein, ich will hier jetzt nicht hören, dass man dann besser eine eigenständige Sache baut und nicht auf ein fertiges Framework zurückgreift. Ich will es einfach nicht hören .. Stichwort: Kompromiss zwischen Arbeitsaufwand und Ertrag!

In diesem Sinne.
Grüße, Ben.

[Ben]

Hier noch ein kleiner Nachtrag:
http://paul-m-jones.com/blog/?p=238#comment-99590

(implementing singletons in PHP4 is definitely slower than PHP5)