nicht angemeldet
Hey dedlfix,
Nur frage ich mich, wo soll dieser Anwendungsfall sein?
Zeig mal genau, was du meinst. Ich finde da grad nichts, worauf deine Beschreibung konkret passt.
ein Beispiel aus dem Quick-Start des Zend-Frameworks:
class Application_Model_DbTable_Guestbook extends Zend_Db_Table_Abstract
{
protected $_name = 'guestbook';
}
Hierbei ist es so, dass die Klasse lediglich den Namen einer Datenbank-Tabelle enthält.
Mir ist allerdings durchaus bewusst, dass die Klasse Zend_Db_Table_Abstract viele weitere Funktionalitäten beinhaltet. Aber, wo wir gerade dabei sind, mir kommt auch diese Klasse, also Zend_Db_Table_Abstract, reichlich "aufgebläht" vor.
Wie bereits gesagt, bei den vorhandenen Frameworks haben sich viele Leute lange Zeit Gedanken drüber gemacht, aber meine derzeit (vielleicht naive) Meinung ist, dass man dies alles wesentlich "schlanker" gestalten könnte.
Und eine abgeleitete Klasse nur wegen eines Tabellen-Namens? Für mich ist dies nach meinem OOP-Verständnis zwar folgerichtig, geht allerdings etwas zu weit.
Außerdem, der Punkt fällt mir grad noch ein: Die aktuell mir bekannten Frameworks bieten viele, ich nenne sie mal "Komfort-Methoden", die meiner Meinung nach nicht sein müssten.
So kann ich einen beispielsweise einen DB-SELECT direkt als SQL-Statement ausführen oder die Funktion select()->from()->was-auch-immer ausführen. Hinzu kommen viele Factory-Methoden (oder Konstruktoren), die ein Objekt, ein Array, einen String oder einen Integer entgegen nehmen können und innerhalb dieser Methode dann entscheiden, "was ich gemeint habe". Mir würde es (in den meisten Fällen) vollkommen reichen, wenn eine Methode ein Objekt eines bestimmten Typs entgegen nimmt. Dies ist ja bereits mit PHP möglich, auch wenn es noch kein vollständiges type hinting unterstützt (was ich persönlich bevorzugen würde).
Fehlerbehandlung ist Sache der Programmteile. Dafür kann es sinnvollerweise keinen globalen Mechanismus geben. Zu vielfältig sind mögliche Ursachen und Reaktionen.
Ok, da habe ich mich falsch ausgedrückt. Bei mir werden im Bootstrap-Prozess mittels set_error_handler() und set_exception_handler() die Klassen initialisiert, die "aufgefangene" Fehler verarbeiten und je nach Umgebung (development, testing, production) unterschiedlich handeln.
Die eigentliche Fehlerbehandlung findet natürlich innerhalb der Anwendung statt. Ich meinte nur die Fehlerbehandlung, wenn beispielsweise eine Methode sagt: "Hier geht's für mich nicht mehr weiter". Hier könnte entschieden werden, ob eine andere Methode übernehmen könnte, ob eine Fehlerseite (abhängig von der Anwendungs-Umgebung) mit oder ohne Fehler-Details angezeigt werden soll oder das Skript mit einem fatal error o.ä. abbrechen muss.
Ein Fehlerlogging-Mechanismus sollte unabhängig von der Anwendung arbeiten. (Natürlich kann er sich dabei der Klassen des Frameworks bedienen, wenn man annimmt, dass diese fehlerfrei laufen und nicht durch selbst erzeugte Fehler eine Endlosschleife oder anderes ungewünschtes Verhalten entsteht.) Fehler sollen ja auch schon dann protokolliert werden (können), wenn der FC nicht geladen werden kann. Denn diese Ursache will man garantiert wissen. Also sollte der Loggingmechanismus (wenn nicht schon außerhalb PHPs konfiguriert) als eine der ersten Amtshandlungen des BS initialisiert werden.
Das mache ich erst im Bootstrapping, da mir erst hier die Konfigurationsdaten zur Verfügung stehen (in einer ini-Datei steht beispielsweise, wo sich das error-log befindet).
Da besteht, Deinem vorherigen Absatz nach zu urteilen, allerdings Nachholbedarf. Ich sollte es wohl ganz an den Anfang der Anwendung packen.
Wieder einmal danke und gute Nacht,
Dennis
Struppi