Singleton, Objekte übergeben oder Statische Klasse

[Tarlar]

Hallo Leute,

ich sitze derzeit an einem größeren Projekt und wollte von Anfang an eine gute Struktur haben. Deshalb stelle ich mir im Moment die Frage wie ich zentrale Klassen, wie Konfiguration, Seitenmanagement in anderen Klassen verwenden kann. Ich habe mir Gedanken über folgende Möglichkeiten gemacht:

1. Singleton-Klassen
   Ich erstelle die zentralen Klassen als Singelton-Klassen und benutze in jeder anderen Klasse den Aufruf Singleton::getInstance(). Habe dabei aber ein mulmiges Gefühl in jeder Klasse 2 oder 3 Klassen durch getInstance() zu bekommen
2. Objekte übergeben
   Ich übergebe jeder Klassen in den Konstruktor die zentralten Klassen. Das ist aber auch nicht viel anders ans die Singleton. Ich müsste auch bei jeder Klasse und jeder neuen Instanz die Objekte übergeben.
3. Statische Klasse
   Ich habe auch schon öfters was von statischen Klassen gehört, weiß allerdings nciht genau was der große Vorteil an denen sein soll und wie sie genau funktionieren.

Was ist denn so der allgemeine Favorit bei euch?

Vielleicht noch etwas zur Verwendung:
Eine Klasse wird zuständig sein für den Seitenaufbau/-management. Sprich überprüfen ob ein User Zutritt hat, oder welche Template geladen werden soll, etc.

Eine weitere Klasse soll sämtliche Konfigwerte enthalten, die in möglichst allen Klassen verfügbar sein sollen.

Danke für die Hilfe

[AmicaNoctis]

Hallo,

aus meiner Sicht ist Variante 2 die einzig saubere. Wenn du die verschiedenen Instanzen der zentralen Klassen in einem Kontext-Objekt sammelst, welches die von den anderen Klassen benötigten Interfaces implementiert, brauchst du auch nur dieses eine zu übergeben.

Gruß,

Amica

[unset]

Gleich kommen wieder die Hardliner, die das Singleton-Pattern verdammen werden. Ob man es einsetzt oder nicht, sollte jedem selbst überlassen sein. Wichtig ist: Singleton nur, wenn man ganz sicher weiß, dass die Instanz in der Tat nur ein einziges mal gebraucht wird. Typische Anwendungsfälle eines Singleton auf die das nicht zutrifft sind zum Beispiel Datenbank-Verbindungen & Request/Response-Objekte. Früher oder später braucht man hier eine weitere Instanz, und schon steht man vor einem Dilemma.

Ich persönlich setze aktiv nur ein einziges Singleton ein, und zwar in Form einer Registry, in die ich einfach alles rein schmeiße, was ich woanders nochmal brauche. Parameter halte ich bewusst ebenfalls so gering wie möglich. Faustregel: Mehr als 3 Parameter, und du hast was falsch gemacht.

Statische Klassen eignen sich für statischen Code –*im Grunde Hilfmethoden, die man ansonsten als Funktionen anlegen würde. Für was anderes würde ich es nicht einsetzen.

Aber am Ende ist es wie so oft: Geschmackssache.

[Slava]

Singleton-Klassen
Ich erstelle die zentralen Klassen als Singelton-Klassen und benutze in jeder anderen Klasse den Aufruf Singleton::getInstance(). Habe dabei aber ein mulmiges Gefühl in jeder Klasse 2 oder 3 Klassen durch getInstance() zu bekommen

kann seinn, dass du die Klassen mit den Objecten verwechselst?
In jedem Fall, liefert Singelton immer nur eine Instance von dem Object, deshalb heisst es auch 'Singelton'

Statische Klasse
Ich habe auch schon öfters was von statischen Klassen gehört, weiß allerdings nciht genau was der große Vorteil an denen sein soll und wie sie genau funktionieren.[/list]

Was ist eine statische Klasse?
Ich kenne nur Statische Methoden und statische Variablen, die auch Objecte sein können .

In jedem Fall passt bei deiner Konfigurationsobject der Singelton ziemlich gut.

[AmicaNoctis]

Was ist eine statische Klasse?

Eine statische Klasse ist eine, die ausschließlich aus statischen Members (statische Properties und statische Methoden) und Konstanten besteht, also nichts anderes als ein funktionsbasiertes, monolithisches PHP-Skript mit "class NAME { ... }" umgossen, "const" statt "define" und "public static" vor jedem Member.

[Tarlar]

kann seinn, dass du die Klassen mit den Objecten verwechselst?
In jedem Fall, liefert Singelton immer nur eine Instance von dem Object, deshalb heisst es auch 'Singelton'

Richtig müsste es natürlich "Habe dabei aber ein mulmiges Gefühl in jeder Klasse 2 oder 3 Objekte durch getInstance() zu bekommen."

Ich sehe den Vorteil bei Singleton darin, dass ich die Objekte einmal im Konstruktor lade und nicht bei jedem neuen Objekt die Objekte der Konfigklasse übergeben muss!

[AmicaNoctis]

Ich sehe den Vorteil bei Singleton darin, dass ich die Objekte einmal im Konstruktor lade und nicht bei jedem neuen Objekt die Objekte der Konfigklasse übergeben muss!

Das hast du richtig erkannt, aber das birgt auch Nachteile, die das Singleton-Pattern in Verruf gebracht haben:

1. Du kannst keine vernünftigen automatischen Tests bauen.
2. Du erkennst die Abhängigkeit zwischen den Klassen nur am Code und nicht an der Methodensignatur
3. Du kannst später nicht vernünftig davon ableiten.

... und sicher noch weitere, die mir grad nicht einfallen.

[Slava]

Eine statische Klasse ist eine, die ausschließlich aus statischen Members (statische Properties und statische Methoden) und Konstanten besteht, also nichts anderes als ein funktionsbasiertes, monolithisches PHP-Skript mit "class NAME { ... }" umgossen, "const" statt "define" und "public static" vor jedem Member.

mit anderen Worten ein Ersatz für NAMESPACE.
Du hast Recht. In diesem Kontext die Bezeichnung 'statische Klasse' ein Sinn hat.

[combie]

Gleich kommen wieder die Hardliner, die das Singleton-Pattern verdammen werden.

Genau!
So einer bin ich!


Meine Ansicht:
In einem Framework oder einer auf Wiederverwendbarkeit ausgelegten Klassenbibliothek haben Singletons nix zu suchen. Ob irgendwas ein Singleton ist, oder sich so verhalten soll, ist eine Anforderung der konkreten Applikation. Diese Anforderung in die universelle Bibliothek zu transportieren halte ich für unklug.

Die wichtigsten Gründe, welche gegen Singletons sprechen, hat AmicaNoctis schon genannt.

[Slava]

Genau!
So einer bin ich!


Meine Ansicht:
In einem Framework oder einer auf Wiederverwendbarkeit ausgelegten Klassenbibliothek haben Singletons nix zu suchen. Ob irgendwas ein Singleton ist, oder sich so verhalten soll, ist eine Anforderung der konkreten Applikation. Diese Anforderung in die universelle Bibliothek zu transportieren halte ich für unklug.

Die wichtigsten Gründe, welche gegen Singletons sprechen, hat AmicaNoctis schon genannt.

Wenn PHP mit Statischen Methoden allgemein die Probleme hat, ist aber kein Grund von einem Singelton abzuraten.
Die von AmicaNoctis beschriebene 3 Gegenargumente kann ich nur bedingt nachvollziehen.

für eine Primitive Bibliothek könnte vielleicht Singelton unnötig sein, aber bei einem Framework, bei dem mehrere Zusammenhänge und Abhängigkeiten zwischen Modulen bestehen wäre es unklug auf Singelton zu verzichten.

[AmicaNoctis]

Die von AmicaNoctis beschriebene 3 Gegenargumente kann ich nur bedingt nachvollziehen.

Was kannst du denn nicht nachvollziehen?

für eine Primitive Bibliothek könnte vielleicht Singelton unnötig sein, aber bei einem Framework, bei dem mehrere Zusammenhänge und Abhängigkeiten zwischen Modulen bestehen wäre es unklug auf Singelton zu verzichten.

Genau anders herum sehe ich es.

[combie]

für eine Primitive Bibliothek könnte vielleicht Singelton unnötig sein, aber bei einem Framework, bei dem mehrere Zusammenhänge und Abhängigkeiten zwischen Modulen bestehen wäre es unklug auf Singelton zu verzichten.

Dem kann ich nicht zustimmen.
Singletons schaffen (unnötige) Abhängigkeiten zwischen den Klassen. Diese Abhängigkeiten erweisen sich später häufig als "Klotz am Bein".

[AmicaNoctis]

Dem kann ich nicht zustimmen.
Singletons schaffen (unnötige) Abhängigkeiten zwischen den Klassen. Diese Abhängigkeiten erweisen sich später häufig als "Klotz am Bein".

Ergänzung: Abhängigkeiten gibt es immer, aber Singletons schaffen hartgecodete Abhängigkeiten (tight coupling), während die Übergabe von Parametern auswechselbare und gut erkennbare Abhängigkeiten (loose coupling) schafft.

[onemorenerd]

Static call versus Singleton call in PHP Hardcoded

[Tarlar]

Es geht bei mir um eine solche geringe Anzahl an aufrufen. Da kann man nicht diesen Performancevergleich zu Rate ziehen.

Aber ich sehe schon, dass die Meinungen stark auseinandergehen und es schlussendlich doch Geschmacksache ist, für welche Alternative ich mich entscheide!