nicht angemeldet
Moin!
bei mir ist ja zur zeit:
jede Klasse extends main Klasse extends datenbankklasse mit funktionen extends datenbankklasse mit connect,close funktion
Ich denke, dein bisheriger Denkfehler bzw. das (noch) Nichtverständnis von OOP ist, auf welche unterschiedlichen Arten Objekte miteinander interagieren können.
Die eine denkbare Methode hast du schon herausgefunden: Vererbung. Das ist eine Möglichkeit, und PHP erlaubt zum Glück keine Mehrfachvererbung (damit kann man sich die schönsten Gehirnknoten basteln - und Gehirnknoten sind bei der Softwareentwicklung nie gut).
Was PHP 5 außer der Vererbung mittels EXTENDS erlaubt, und sogar mehrfach, ist das Implementieren von Interfaces. Das allerdings brächte dir keinen unmittelbaren Vorteil, denn eine Interface-Definition legt nur fest, welche Public-Methoden eine Klasse alle haben soll, sie legt aber nicht fest, was diese Methoden real tun, sie definieren nur, welche Parameter eine Methode erwartet. Das ist für den Entwickler also nur eine Gedächtnisstütze, damit er keine zu implementierende Methode vergisst.
Die viel spannendere Interaktion zwischen Objekten ist aber, wenn die Methode eines Objekts als Parameter ein anderes Objekt übergeben bekommt. Du kannst also beispielsweise den Zugang zur Datenbank als Instanz der MySQLi-Klasse realisieren, und dieses Objekt jeder Klasse mit übergeben, die Datenbankzugriff realisieren muss. Und zwar eben nicht als Vererbung, sondern als Parameter beispielsweise dem Konstruktor des Objekts. Wenn der Konstruktor sich dieses Objekt in einer protected-Variablen speichert, können alle weiteren Methoden auf die Datenbank zugreifen, indem sie das gespeicherte Objekt verwenden.
Und da kommen dann die sogenannten Design-Patterns recht schnell ins Spiel: Es wäre sowohl Verschwendung an Speicherplatz, als auch belastend für die Datenbank, wenn ein einziges Skript für seine vielleicht zehn datenbankzugreifenden Objekte auch zehn Datenbank-Connections benutzen würde. Deshalb möchte man vermeiden, dass sich das Objekt für den direkten Datenbank-Kontakt unendlich dupliziert, und realisiert dies, indem man dieses Objekt mit dem Singleton-Pattern erstellt.
Aber Vorsicht: Das Singleton-Pattern verleitet sehr leicht zum Mißbrauch. Im Prinzip ist dieses Pattern die Reinkarnation von globalen Variablen mit anderen Mitteln. Für den Datenbankzugriff ist es vermutlich meistens gerechtfertigt, in vielen anderen Fällen eher nicht.
Toms Anmerkung hat allerdings ihre Berechtigung: Man kann OOP auch übertreiben. Und vor allem bei OOP-unerfahrenen Entwicklern überwiegt erstmal die Faszination, alles rein mit OOP machen zu wollen, und der Realismus tritt in den Hintergrund.
Die Mischung macht es. Wenn du bislang prozedural programmiert hast (und hoffentlich vernünftig), dann wäre ein guter Zwischenschritt, die grundlegende Skript-Logik erst einmal weiterhin so laufen zu lassen, aber anstelle der diversen Funktionen Objekte einzuführen, die begrenzte Aufgaben erledigen. Das Zusammenführen der Objekte geschieht dann im OOP-losen "Hauptprogrammteil" des Skripts.
- Sven Rautenberg