2 Klassen initialiseren sich gegenseitig

Zitat von combie

Und warum ist der Shop Singleton?
Singletons sind böse !

Und mal wieder:
Mache dich über "Dependency Injection" kundig.
(für alle, welche schon wieder darauf gewartet haben)

*räusper*

Ich wollte selbst schon damit anfangen, hab's dann aber doch sein lassen.

Aber eins würde mich noch interessieren.
Wieso sind Singletons nun böse?^^

Die Vererbung bleibt auf der Strecke. Ein wichtigen Kapitel der OOP grenzt du damit aus.
(OK, unter PHP5.3 ist das Problem durch erheblichen Aufwand lösbar, mit älteren Versionen nicht)

Häufig werden Singletons als $GLOBALS Ersatz verwendet. Da schleppt man trotz Paradigmenwechsel die alten Probleme mit.

Usw.
Zu diesem Glaubenskrieg gibts massig im Netz zu finden.



Beispiel:
Du schreibst einen Shop!
Dieser ist nur für einen Händler gedacht.

14 Tage später brauchst du noch einen Shop.
Also kommst du auf die Idee den Shop multi Mandanten fähig zu machen.
In dem Zuge baust du dir ein übergeordnetes SuperAdminTool für alle Shops.

Oha!
Da ist es schon: "für alle Shops"
Schluss, aus, mit Singleton!
(alles wieder umstricken, von Grunde auf)

zumal das möglicherweise beim Shop noch einen kleinen Sinn haben mag - aber beim Angebot nicht mehr... jedenfalls nach meinem Verständnis hat doch ein Shop mehrere Sachen im Angebot ....

Zitat von eagle275

zumal das möglicherweise beim Shop noch einen kleinen Sinn haben mag - aber beim Angebot nicht mehr... jedenfalls nach meinem Verständnis hat doch ein Shop mehrere Sachen im Angebot ....

Der Fehler beim TE besteht schon mal darin das die Shop Klasse mehrere oder einige Members oder Methoden aus der Angebotsklasse benötigt. Das ist schon mal ein ganz böser Software Design Fehler (dabei rede ich nicht von Design Patterns).

Bei einem Shop hat ein Singleton Pattern absolut null Sinn, ich schrieb ja schon, mir ist momentan auch noch kein Fall untergekommen wo ich wirklich nur eine einzige Instanz auf eine Klasse haben darf und auch wenn ich ne Weile drüber nachdenke fällt mir da nichts sinnvolles ein, was aber vieleicht auch daran liegen mag, dass ich noch nicht so lange mit OOP zu tun habe und mache.

Zitat von litterauspirna

und auch wenn ich ne Weile drüber nachdenke fällt mir da nichts sinnvolles ein

Ist wohl eines der am häufigsten genutzten Patterns. Spontan würde mir da bspw. ein logger einfallen

Zitat von ThemBones

Spontan würde mir da bspw. ein logger einfallen

Den würde ich auch über Dependency Injection einbinden, dann kann ich in der Testphase einen zum Debuggen verwenden und im Produktiveinsatz einen anderen.

Das größte Missverständnis bei Singletons ist meiner Meinung nach die Verwechslung dieser beiden Fälle:

• Ich brauche im Moment nur eine Instanz dieser Klasse.
• Es darf unter allen Umständen jetzt und in Zukunft immer nur eine (und immer dieselbe) Instanz geben.

Der zweite Fall kommt nur sehr selten vor und lässt sich fast immer vermeiden bzw. umschiffen.

Zitat von AmicaNoctis

• Ich brauche im Moment nur eine Instanz dieser Klasse.
• Es darf unter allen Umständen jetzt und in Zukunft immer nur eine (und immer dieselbe) Instanz geben.

Nun, es fängt schon dabei an die Begriffe "im Moment" oder "immer" auseinanderzuhalten und klar zu defninieren. Bezogen auf die Lebenszeit des Prozesses? Der Daten?

DI ist sicherlich eleganter. Meiner Meinung nach ist aber ein Logger, der genau in eine Datei schreiben soll, eine der wenigen Anwendungsfälle in der ein Singleton Sinn macht? (nicht, dass mir jetzt einer einen Strick draus dreht: "macht in wenigen Fällen Sinn" und "eines der am häufigsten genutzten Patterns" sind leider zwei Dinge, die sich nicht notwendigerweise ausschliessen).

Naja ist wohl zu einem gewissen Anteil Frage des persönlichen Geschmacks.
Ich bin dann mal weg, bevorzuge es jeglichem Glaubenskrieg aus dem Weg zu gehen bevor es soweit kommt

Es hat sich ja mittlerweile eine sehr interessante Diskussion entwickelt.

Aber dass man Singletons sehr selten benutzt kann ich nicht bestätigen.
Hier mal ein paar Beispiele wo und warum ich die Klassen als Singleton benutze:

Functions.class
- Das ist eine Sammlung von unzähligen allgemeinen Funktionen. Die resultiert daraus, da das Projekt vorher strukturiert war und alle Funktionen statisch deklariert wurden um die dann aufzurufen. Sie wird nach und nach gekapselt, aber puntk ist, dort sammeln sich allgemeine Funktionen die an mehreren Stellen benötigt werden. Die Klasse ist ein Singleton, da ich nicht verschiedene Zustände der Klassenvariablen benötige o.ä. sondern einfach nur eine Möglichkeit haben möchte, um auf die Klasse zuzugreifen. Die Funktionen sind nicht mehr statisch, da einige Klassenvariablen initialisiert wurden, die in fas tallen Funktionen benötigt werden etc.

Model.class
- Ich benötige nur eine einzige Instanz, da ich immer auf dieselbe Datenbank zugreife

Router.class
- Eine Klasse die mir die entsprechenden Seitenaufrufe den entsprechenden Controllern zuordnet, etc.
Wieso sollte es kein Singleton sein?
Das Interpretieren des Seitenaufrufs geschieht einmalig, und die Werte werden dann aber an mehreren Stellen benötigt, also rufe ich dann entsprechende Klassenvariablen auf um die Werte zu erhalten. Mit Obejtken hätte ich immer andere Werte.

Request.class
- Eien Wrapperklasse die mir die Request Variablen escapet etc. Auch hier benötige ich keine Objekte, da es sich immer um dieselben Daten handelt.

Soviel dazu.
Ich freue mich über eure Meinungen und ideen, wieso und warum meine Ansicht evlt. falsch oder sogar richtig sind.

Vielen Dank im voraus.

@dakingno1: Das sind alles Beispiele für Situationen, wo man Singletons gerade nicht benutzen sollte. Warum, kannst du an verschiedensten Stellen selbst nachlesen, z. B. hier: Singleton pattern - Wikipedia, the free encyclopedia

Wenn man einmal begriffen hat, wie ein Hammer funktioniert, dann sieht die ganze Welt plötzlich wie ein Nagel aus!