OOP mit PHP5 - Praxistutorial 1 - Zusammenfassung
1. Die Abschnitte
- Einführung
- Konstruktor und Destruktor der Db-Klasse
- Konstruktor der Db_Request-Klasse
- Der erste Zugriff
- SQL-Fehler abfangen
- Zusätzliche SQL-Methoden
- Die Auswertungsschicht
- Abfragen
- Zusammenfassung
2. Fehlerbehandlung
Hier haben wir eine (relativ) saubere Trennung zwischen unerwarteten und groben Fehlern bei den SQL-Statements geschaffen. Bei Syntaxfehlern
fliegt uns eine Exception um die Ohren, ansonsten werden die Meldungen umgeleitet. Es wäre jetzt also die Aufgabe der
oop_4.php, diese sauber zu verarbeiten. Zum besseren Verständnis zeige ich noch mal das Grundkonzept.
-
Verbindungsfehler zur Datenbank werden umgeleitet.
- Der Konstruktor der
Db-Klasse versucht, eine Verbindung aufzubauen und wirft ansonsten eine Exception. - Der Konstruktor der
Db_Requestfängt den auf und gibt ihn in der Eigenschaft$messagezurück. ***
- Der Konstruktor der
-
Alle SQL-Anfragen werden von einer(!) Methode ausgeführt.
- Sind diese syntaktisch falsch, so wird eine Exception geworfen. Da dies ein Fatal Error ist, wird sie direkt ausgegeben, kann also nicht abgefangen werden.
- Anderenfalls wird in der
Db-Klasse die Ressourcenkennung in der (fast) gleichnamigen Eigenschaft abgelegt.
-
Wenn ein Query erfolgreich ausgeführt wurde, so wird direkt im Anschluss eine entsprechende Methode ausgeführt, die über die oben
erwähnte Ressourcenkennung das Ergebnis auswertet.
- Wenn konkrete Werte zurückgeliefert werden, so erfasst sie die jeweilige Methode der
Db_Request-Klasse. - Ansonsten werden die entsprechenden Informationen der
Db-Klasse ausgewertet.
- Wenn konkrete Werte zurückgeliefert werden, so erfasst sie die jeweilige Methode der
- Deren Auswertung liegt nun in den Händen der
oop_4.php.
*** Anmerkung
Eigentlich ist $message im Sinne der reinen Lehre keine richtige Eigenschaft. Denn es werden nur Meldungen in einem Array
gebündelt. Zumindest kann man geteilter Meinung darüber sein. Ich persönlich habe dazu eine pragmatische Einstellung. Oder genauer gesagt,
ich mache das aus reiner Faulheit. Da spare ich mir return-Orgien und greife direkt im Objekt darauf zu. Vielleicht nicht sehr
schön, vielleicht nicht sehr fein, aber das juckt mich persönlich wenig. Behaltet aber den Hinweis im Hinterkopf.
3. Der Lösungscode
Hier habe ich ein paar zusätzliche Methoden in beide Klassen eingebaut. So kann man Datensätze löschen oder einen beziehungsweise mehrere suchen. Gut, dass ist nicht vollständig. Es fehlt zum Beispiel die Möglichkeit, die Anzahl von bestimmten Daten zu ermitteln. Hier geht es aber (wie immer) nur um grundsätzliche Dinge.
Tipp!
Schaut euch den Lösungscode mal genau an und spielt damit herum. Versucht ruhig, alle möglichen Fehlerquellen entsprechend zu verarbeiten und ergänzt die Klassen nach euren Wünschen. Haut so richtig auf die K***cke und tobt euch aus. Denn eines solltet ihr mittlerweile wissen. Man lernt nur aus Fehlern!
4. Die Sache mit der fehlenden Vererbung
Hier kann man wieder trefflich streiten, ob die Vorgehensweise optimal ist oder nicht. Also zuerst folgende Feststellung. Optimal ist nach meinen Erfahrungen bei der Programmierung eigentlich nichts. Im Nachhinein kann man immer etwas verbessern. Außerdem entspricht das nicht der Originalprogrammierung, da es dort noch eine eigene Klasse zur Fehlerbehandlung gab. Und die Sichtbarkeitsstufen ein wenig anders waren. Die hab ich hier einfach weggelassen. Aber das tut den grundsätzlichen Prinzipien keinen Abbruch, wenn ihr sie denn verstanden habt.