nicht angemeldet
Moin!
Wie gesagt, wenn von der Klasse etwas "gemacht" wird, dann finde ich den Einsatz logisch. Wenn eine Klasse nur Abbild von Daten ist, die ich auch auf einfacherem Wege aus der DB bekomme, dann sehe ich da nicht so den Sinn.
Ich habe einen Webshop geschrieben, der auch Klassen benutzt. Einige waren fertige Projekte, z.B. die Klassen für Templates und Mailversand. Der eigentliche Shop sind meine eigenen Klassen.
Ein Shop braucht natürlich Zugriff auf eine Datenbank. Also fing ich mit einer Klasse "DB" an, welche die Verbindungsdaten zur Datenbank erhält und sämtliche Zugriffe auf die Datenbank kapselt. Nirgendwo außerhalb der DB-Klasse sollte auch nur das kleinste Fitzelchen SQL stehen.
Außerdem braucht ein Shop natürlich auch Sessions, um z.B. den Warenkorb zu speichern. Also schrieb ich noch eine Klasse "Session", welche sämtliche Funktionen enthält, die auf $_SESSION zugreifen. Nirgendwo außerhalb dieser Klasse sollte Zugriff auf $_SESSION genommen werden.
Und das allererste Problem, auf das ich stieß: Die Session-Klasse benötigt irgendwie Zugriff auf die Datenbank - wie soll das gehen?
Ich habe mich dann entschieden, dass die Session-Klasse die DB-Klasse erweitern (extends), also alle DB-Funktionen erbt, und die eigentlichen Shop-Skripte dann jeweils nur die Session-Klasse instanziieren. Ich habe also am Ende ein sehr monolithisches Shop-Objekt, was alles kann (Session- und DB-Zugriff).
Dieses Objekt speichere ich aber absichtlich nicht in der Session ab, weil es nichts bringen würde. Der einzige Sinn, ein Objekt in der Session zu speichern wäre, um bestimmte Variablen im Objekt zu retten und weiterzuverwenden. Sämtlicher Rest, nämlich der ganze Programmcode der Klasse, muß in jedem Skript immer wieder neu includiert und ausgeführt werden. Und auch die Verbindung zur Datenbank kann ja nicht per Session gerettet werden. Da der Shop auf PHP4 basiert, gibts auch keine "Rettungsfunktionen", die die DB-Verbindung vor dem Serialisieren schließen und nach dem Deserialisieren neu herstellen können.
Die strenge Trennung von Zugriffen (kein SQL außerhalb der DB-Klasse, kein Zugriff auf $_SESSION außerhalb der Session-Klasse - das sind zwei getrennte Include-Dateien) erleichtern die Wartung des Shops erheblich. Es ist für den gesamten restlichen Shop vollkommen egal, wie die Datenbank aufgebaut ist (da hat sich im Laufe der Zeit einiges verändert), solange die DB-Methoden zur Abfrage immer die gleichen Ergebnisse ausliefern. Veränderungen in der Datenbank lassen sich so sehr leicht kapseln.
Das Gleiche gilt für $_SESSION. Hier war ich zwar nicht ganz so konsequent und habe ein paar Lesezugriffe außerhalb der Klasse zugelassen, aber im Prinzip erlaubt diese Kapselung, dass die Session komplett eigenständig über die ideale Speicherung der notwendigen Warenkorb- und Kundendaten entscheidet, und lediglich das einmal in der Methode definierte Rückgabeformat einhalten muß. Erweiterungen im Rückgabeformat erzwingen eine neue Methode - die alte Methode muß kompatibel zu sich selbst bleiben, egal wie sie das macht (also entweder den alten Code beibehalten, oder z.B. die neue Methode aufrufen, und überflüssige Daten wegwerfen, um das erwartete Datenformat zurückgeben zu können.
Ich würde meinen Ansatz aber nicht wirklich objektorientiert nennen. Ich habe irgendwie das Gefühl, man muß in PHP nicht bis ins letzte mit Objekten arbeiten - zumal man davon nicht wirklich etwas hat, weil alle Objekte bei jedem Skriptstart wieder komplett neu hergestellt werden müsse - sie bleiben ja nicht von selbst im Speicher. Die Klassen dienen nur zur Kapselung der Funktionen in einem eigenen Namensraum, damit nicht unerwartet irgendwelche Konflikte auftreten. Die Vorgehensweise ist dabei sicherlich noch verbesserungswürdig - allerdings habe ich in den ganzen Jahren, die ich den Shop jetzt weiterentwickle, noch keinen Drang verspürt, nochmal komplett neu anzufangen. Alle bisherigen Ausbauten waren mit dem bisherigen Konzept prima verein- und realisierbar.
- Sven Rautenberg
My sssignature, my preciousssss!