Hallo Thorsten,
Ganz am Anfang: Vielleicht findest Du unter </archiv/2002/12/31778/> auch ein paar interessante Anregungen.
So weit so gut, nun hab ich entschieden diese um eine Klasse errorReporting zu erweitern, welche Fehlermeldungen und Ereignismeldungen verwaltet. Weiter gibts eine Klasse die Beispielsweise Thumbgrafiken erzeugen kann.
Hmmm. Ich an Deiner Stelle würde Backend und Frontend sauber trennen. Du hast dann ein paar Klassen, die die Backgroundarbeit erledigen (fileUpload, thumbnail, etc.) und ein paar Klassen, die sich um die Benutzerinteraktion kümmern und die Backendklassen verwenden.
Nun ist aber eigentlich auch so, das ja meine fileUpload-Klasse selbst nicht wirklich davon abhängig ist Fehlermeldungen speichern zu können. So mache ich sie jedoch abhängig davon. Wäre es vielleicht nicht sinnvoller auch die errorReporting-Klasse nur bei Bedarf zu Instanzieren?
Du kannst es ja wie PEAR machen, Du kannst eine Fehlermeldungsklasse definieren, und diese bei Bedarf als Rückgabewert von Funktionen zurückgeben. Du kannst dann in Deinen Scripten prüfen, ob ein "normaler" Rückgabewert zurückgegeben worden ist, oder das Fehlerobjekt.
Macht es Sinn in der Praxis, alle Klassen die man zwar brauchen könnte, jedoch nicht unbedingt benötigt in einer Klasse bei Bedarf zu Instanzieren?
Ja.
Oder leidet die übersichtlichkeit und Transparenz irgendwann darunter?
Wieso sollte sie?
Ich mache mir gerade megaviele Gedanken, wie ich Klassen so gestalten kann, die sie so eigentständig wie möglich funktionieren und welche Aufbau wirklich sinn macht.
Das ist gut so. Ein gutes Konzept ist immer sehr wichtig, warscheinlich das Essenziellste einer guten Software. (neben der Dokumentation)
oder kennt ein Tutorial das nicht auf Einsteigerniveau liegt, davon gibts genug.
Der Archivlink oben... ;-)
gl & hf
gl? hf?
Grüße,
Christian
Ich bitte darum, dass ein Themenbereich (BARRIEREFREIHEIT) eingerichtet wird.