Klassensammlung

[ulle]

Hallo liebe Community,
ich bin im Moment dabei meine gesamte Klassensammlung zu einem kleinen für meine Projekte verwendbares Framework zusammen zubauen.
Jetzt steh ich im Moment vor einer kleinen Problemserie.

Im Moment setze ich folgende Entwurfsmuster ein:

• Registry
• MVC
• FrontController
• Request und Response (Wobei das nen Streit Pattern ist aber das soll nicht sinn dieses Threads sein)
• Singleton

Desweiteren habe ich eine sogenannte PageController Klasse, welche meine Hauptklasse des Systems darstellt und welche in jeder Anwendung als erstes includiert werden MUSS!!

Alle meine Unterklassen, sei es der Frontcontroller oder die Request und Response geschichte, instanziere ich im PageController und hau die nach dem instanzieren in die Registry. Soweit ganz gut. Allerdings wenn ich nun eine der Klassen brauche, muss ich mir vorher immer das Objekt aus der Registry holen

Code: Alles auswählen

$response = Registry::get('response')

Wäre es dann nicht besser auch diese Klassen durch das Singleton Pattern zu ersetzten, damit ich mir diesen unötigen Aufruf ersparen kann? Ich könnte ja dann in den Klassen einfach per

Code: Alles auswählen

Request::getParameter('parametername')

drauf zugreifen und die Sache wäre geritzt. Haltet ihr das für sinnvoll oder ist es nach wie vor nicht sehr ratsam das Singleton Pattern einzusetzten?

Lieben Gruß und danke schon jetzt
Ulle

[splasch]

Um direkt auf eine Methode zu zugreifen muss es nicht umbedingt ein Singleton Pattern sein. Wichtig ist nur das dein Framework auch die Klasse findet. Je nach Framework ist das ein wenig unterschiedlich. So müssen bei dem einen fremde Module vorher in einer Konfiguration Datei eingetragen werden. So das später auch dort nach der Klasse automatisch gesucht wird.

Ein Statisch Aufruf ist nicht gleich ein Singleton Pattern! Es reicht also aus wenn die Methode direkt aufgerufen wird. Wenn du allerdings einen Singleton Pattern verwirklichen willst musst du dafür sorgen das es das Objekt nur einmal geben kann. Das kannst du erreichen in dem du die Klasse auf Private setzt so das daraus mit new kein Objekt mehr erzeugt werden kann.

Mfg Splasch

[ulle]

Also mit anderen Worten wäre es dann ratsam die Methoden Statisch zumachen. So könnte man den Aufruf ja wie oben belassen und spart sich auch noch die Singleton Implementation. Sehe ich da richtig? Und mit dem finden Klasse hängt doch mit dem autoloader zusammen oder? Den kann ich ja in die richtige Richtung leiten :D so das er diese aufjedenfall findet.

Gruß Ulle

[Basti]

Du solltest dir unbedingt überlegen, ob es überhaupt Sinn macht, dass es nur ein Request-Objekt geben kann. Auf lange Sicht halte ich persönlich dies nicht für ratsam. Ich selbst arbeite mit dem Zend Framework, wo es durchaus einmal vorkommen kann, dass ein Request-Objekt geklont oder neu erzeugt wird, um es gegen das aktuelle Request-Objekt auszutauschen. Es kann durchaus Anwendungsfälle geben, in denen man auf beiden Objekten arbeiten muss, weshalb es nicht ausreichen würde, eine einzige Singleton-Instanz zur Verfügung zu haben.
Dir mögen solche Szenarien zwar noch unwahrscheinlich erscheinen, derart grundlegende Komponenten wie ein Request-Objekt sollten aber immer vorausschauend entworfen werden, da späte Änderungen häufig ein zeitaufwändiges Refactoring in abhängigen Komponenten bewirken können.

Am Ende noch einmal kurz zu statischen Methoden und dem Singleton-Pattern. Statische Methoden können durchaus Workflows vereinfachen, weshalb ich sie beispielsweise auch gerne für den Zugriff auf Objekte in einer Registry nutze.
Im Allgemeinen sollten statische Methoden aber in erster Linie dazu genutzt werden, im Klassen- und nicht im Objekt-Kontext zu arbeiten. Wenn du nun eine Singleton-Implementierung vornimmst, bei der alle statischen Methodenaufrufe an das interne Singleton-Objekt weitergeleitet werden, führt das mitunter zu vielen zusätzlichen Methoden, die im Grunde keine zusätzliche Funktionalität implementieren. Darunter kann dann auch das Verständnis der Abläufe leiden.
Deshalb wird bei einer Singleton-Implementierung häufig nur eine öffentliche statische Methode getInstance() angeboten, während der Konstruktor und die __clone() Methode als protected bzw. private deklariert werden. Nachdem die Singleton-Instanz geholt wurde, wird dann ausschließlich auf dieser gearbeitet.

[ulle]

Es geht mir halt hauptsächlich darum das ich eine Möglichkeit schaffen möchte welches mir erlaubt direkt auf die im PageController Definierten Klassenobjekte zuzugreifen ohne das ich diese in dem Modulcontroller explizit installieren muss. Natürlich ist das im moment nur für die Request und Response Klasse aber später sollen ja noch weitere folgen welche den Arbeitsfluss verbessern können. Ich findes es halt irgendwie umständlich wenn ich mir die Objektinstanz erst aus der Registry holen muss bevor ich diese nutzen kann. Es soll halt so flexibel wie möglich sein. Die Problematik von Singleton ist mir durchaus bewusst und ich versuche es auch nur da einzusetzen wo es absolut nicht anderst geht (registry Pattern). Wenn es eine andere Möglichkeit gibt mit der ich ich ohne die Objekte aus der registry auf von mir gewünschte Klassen zugreifen kann, dann sagt es mir. Ich lass mich gerne belehren Natürlich könnte ich im PageController alle Klassen installieren und Objekte erzeugen. Aber dann hat man bei einer großen Klassensammlung ja ein Overloading bei jedem Aufruf. Das will ich ja vermeiden. Am besten sollte halt alles erst zur Laufzeit hinzugefügt werden. Als Pattern würde mir da das Depency Injection Pattern (schribt man das so?) einfallen. Vielleicht habt ihr ja noch eine Idee wie ich das am besten umsetzten könnte.

Gruß ulle

[Basti]

Leider ist mir deine Architektur noch nicht ganz klar, was ich so lese klingt aber eher danach als wäre es komplizierter als es eigentlich sein muss.

Dependency Injection (ja, ist richtig so ) halte ich definitiv für die bessere Lösung. Request- und Response-Objekte können beispielsweise vom FrontController verwaltet und bei Bedarf explizit durch DI an andere Komponenten weitergereicht werden. Insbesondere sollten derartige Objekte nicht global über die Registry erreichbar sein, da andernfalls nicht mehr gesteuert werden kann, welche Komponenten überhaupt Zugriff auf die Objekte erhalten (Stichwort Information Hiding).
Ein guter Anwendungsfall für eine Registry ist hingegen ein Objekt für den DB-Zugriff global verfügbar zu machen.

Ich weiß nicht wie lange du schon objektorientiert unterwegs bist, ich empfehle dir aber, weniger global zu denken als das bspw. bei der prozeduralen Programmierung üblich ist. Konkrete Objekte sollten immer nur dort verfügbar sein, wo sie auch benötigt werden. Darüber hinaus sollten aggregierte Objekte nur aus dem internen Gedächtnis eines Objekts oder einer Klasse herausgegeben werden, wenn dies auch unbedingt notwendig ist.
Das MVC-Pattern bietet bereits eine gute Grundlage für einen sauberen Aufbau von Schichten.

Ich hoffe ich konnte dir damit ein paar Denkanstöße geben.

PS: Gerade bei der Implementierung von Kern-Komponenten kann es nie schaden, einen Blick auf die Lösungen anderer Entwickler zu werfen. Für die Komponenten mit denen du dich zur Zeit beschäftigst besitzen eigentlich alle gängigen Frameworks eine Implementierung, und gerade der Vergleich kann durchaus spannend sein auch wenn du dich für eine andere Lösung entscheidest.

[ulle]

Besteht zufällig die Möglichkeit das mir einer das DI kur erläutern kann? Was die genauen Vorteile sind und wie man es am besten einsetzt? Alles was ich beim googln finde ist nicht sehr aufschlussreich für mich. Wobei das bestimmt an meinen mangelnden English Kenntnissen liegt. :D

Falls mir das jmd irgendwie für Idioten auf Deutsch erläutern kann, wäre ich sehr dankbar.

Gruß
Ulle

[Basti]

Ich habe dir mal ein paar Links zum Thema Dependency Injection zusammengesucht, da die aufgelisteten Seiten meiner Meinung nach einen besseren Überblick über dieses Thema geben, als ich das hier in wenigen Sätzen tun könnte.

• DI auf Wikipedia (englisch, aber gut verständlich)
• DI bei ITWissen
• Slideshow mit PHP-Beispielen

Sollten im Anschluss noch Fragen auftauchen, kannst du dich einfach wieder hier zu Wort melden.