Dred: OOP php: verschachtelte Klassen und ein Zugriff auf eine Eigensc

Beitrag lesen

Könnt ihr mir helfen. Ich programmiere noch nicht lange OO.

Merkt man. Dein OOP-Konzept ist ziemlich grausig!

DAnke für diesen Spruch, Du hochnäsiger Mensch. Ich hätte 100€ verwettet, dass so ein Spruch auf meinen Satz folgt. Du hast ja auch echt ne Menge von meinem Code gesehen, um das sagen zu können.

Nachdem das gesagt ist, wende ich mich nun Deiner Antwort zu.

Vielen Dank für deine Antwort.

Es ist so, das der Beispielcode nur ein Bruchstück darstellt. Und im Kontext macht es mehr Sinn, die DB im Constructor der Site zu instantiieren. Denke ich. Es ist auch nicht nur eine DB, daher mag ich das mit dem Parameter nicht.

Generell gilt bei meinem Projekt: alle Klassen sollen annähernd stand-alone-fähig sein. Das heisst, jede Klasse kümmert sich erstmal selbst um seine Exceptions. Natürlich verwende ich throw, try u. catch. Ich wende es, denke ich, ziemlich sauber an. Warum hängst Du Dich so an dem Beispielcode auf? In annähernd jedem catch steht dann der Code:

  
catch (Exception $e) {  
  
  $this->ExceptionHandler($e);  
  	  
}

Damit landen also alle Exceptions beim eigenen ExceptionHandler(). Dort soll dann jeder, der später mit den Klassen arbeitet, machen, was er möchte. Ich möchte, dass sie dann an das $Site - Object gegeben werden, was ich momentan mit Global $Site, etc.... mache.

Die Frage, die ich gestern bestimmt mißverständlich oder schlecht formuliert habe -

Ja hast Du, häng' den Programmierjob an den Nagel, Junge!

... ja danke, ich weiß - könnte vielleicht besser lauten: Wie kann ich aus einer Klasse heraus die Eigenschaft einer anderen Klasse verändern (Ansätze mit extend würde hier glaube ich nicht so gut passen). Wie kann ich die Exceptions einer Klasse an eine andere delegieren. So, klappt es ja bereits. Global verwende ich tatsächlich nur in diesen ExceptionHandler()'n, sozusagen ganz provokativ.

Alles, was du glaubst tun zu müssen, um mit Exceptions in deinem Verständnis umzugehen, ist vermutlich falsch, weil du es nicht besser kennst - aber da werden wir sicher diverse Hinweise liefern, um das zu ändern.

Vielen Dank. Ich hoffe/glaube ich verwende es nicht völlig falsch. Ich habe zum Beispiel häufig im Constructor ein try-Block, der sich um mehrere Funktionen spannt, in denen ich dann exceptions werfe, die sich dann bis zum Constructor durchschlagen.

An deinem Code ist, wie du dir denken kannst, einiges grausam schlecht designt. Die Tatsache, dass die Site ihren DB-Handler selbst instanziiert, ist problematisch; würde ich nicht so machen, sondern als Parameter dem Konstruktor übergeben, also außerhalb der Site in dem Code, der Site ins Leben ruft.

Würde ich nicht, da es mehrere Instantiierungen sind (würden dann zu viele Parameter). Außerdem finde ich Parameter zu "statisch" in Bezug auf eine Veränderung des Projektes.

Ich kann dir schwerlich was raten, wenn ich nicht weiß, was du warum gemacht hast. Wirfst du Exceptions? Wo? Und was soll das Ergebnis sein, wenn eine geworfen wird.

Ich werfe sie (bspw. in Methoden der Klasse DB) und sie landen beim ExceptionHandler der Klasse DB. Im Ende sollen sie zur Klasse Site, da ich sie dort aus der Eigenschaft Exception (Array) auslese und darstelle.

Exceptions sind, wenn man es böse betrachtet, eine moderne Form von GOTO. Der normale Programmablauf wird verlassen, und im catch-Teil weitergemacht. Deshalb sollte man dieses Mittel eher sparsam einsetzen, insbesondere nicht zur Steuerung des Programmflusses mißbrauchen.

Zugegeben, ich verwende sie zur Programmsteurung. Finde ich aber auch nicht so merkwürdig. Wenn ich eine Funktion habe, die mit einer Datei allerhand Dinge anstellt und ich als erstes im try-Block mal habe if(!file_exists($file)) throw new Exception("File not found.", 1); und damit der weitere Ablauf der Funktion verhindert wird, ist das doch mehr als gewünscht. Oder soll ich jedesmal tolle if-Blöcke bauen um bis zur 14-ten Verschachtelung zu kommen?

Im Prinzip gibt es nur zwei Möglichkeiten, mit Exceptions umzugehen: Entweder, der aufrufende Code einer exceptionwerfenden Funktion kann die Exception fangen, weil er auch mit dem Fehlerfall umzugehen weiß. Das kann beispielsweise in der Bereitstellung eines passenden Ersatzes münden (z.B.: getArrayOfDatabases() -> DbUnavailableException -> catch: return array()).

Alternativ fängt man die Exception eben gerade nicht, sondern lässt sie ganz bis nach "oben" durchschlagen - was dann natürlich nicht ganz so elegant zu einer Fehlermeldung führen würde, weshalb es eine gute Idee ist, auf oberster Codeebene ein pauschales Catch für alle Exceptions einzufügen, welcher den HTTP-Status auf 500 "Internal server error" setzt und dann noch eine hübsche Fehlerseite ausgibt.

  • Sven Rautenberg

Je nach Lage fange ich sie entweder unmittelbar oder lasse sie nach oben durchschlagen.

Vielen Dank für Deine kompetente Hilfe. Bitte verstehe aber, dass ich nicht verstehen kann, wieso das immer so schnippisch ablaufen muss. Ich bin in der Situation des Unwissenden nur auf der Suche nach Informationen. Ich bin nicht faul oder dumm. Ich schätze Deine Hilfe, aber ich schätze nicht diese demotivierenden Kommentare "grausig", "grausame schlecht",...

Liebe Grüße