Mailinglisten-Archive |
Am Sonntag, 9. Januar 2005 11:49 schrieb Ralf Eggert: > Hallo Liste, > > tut mir leid, dass ich die Ruhe an diesem schönen Sonntag stören muss, > aber ich hab da mal ne Frage. > > Ich habe eine Haupt-Klasse coreWebsite, von der sich andere Klassen > (coreForm, coreList) ableiten. Das Ganze sieht in etwa so aus: > > coreWebsite > > +----> coreForm > > +----> coreList Meiner Meinung nach ist das Design an dieser Stelle schon falsch. Wenn coreWebsite eine abstrakte, allgemein gehaltene Seite abbilden soll, dann ist coreForm und coreList ein nicht zwingend notwendiger Bestandteil von coreWebsite. Damit kannst du die Klassen coreForm und coreList nicht von der coreWebsite Klasse ableiten. In Eorten könnte man die Beziehung folgendermaßen beschreiben: "coreForm ist nicht coreWebsite" -> keine 'is a' Beziehung "coreForm ist ein Teil von coreWebsite" -> eine 'part of' Beziehung. Gleiches gilt für coreList und andere Bestandteile einer Website. Praktisch bedeutet das, dass du der Instanz von coreWebsite (oder einer von ihr abgleiteten Klasse) eine Instanz von coreForm bzw. coreList übergibst, natürlich wenn notwendig, also, wenn eine Seite tatsächlich ein Formular beinhaltet. Es kann aber auch sein, dass es mehrere Formulare auf einer Seite gibt. Somit kannst du für jedes Formular eine Instanz der Klasse coreForm der Instanz coreWebsite übergeben. Bsp.: class coreWebsite { /** * Liste von Referenzen auf die Instanzen von coreForm * * @access private * @var array */ var $coreForm = array( ); [...] /** * Registriert eine Referenz auf die Instanz von coreForm * * @access public * @param coreForm & $form * @return bool * ... */ function RegisterCoreForm( & $form ) { // Parameter prüfen // ... $this->coreForm[ ] =& %form; } } > > coreWebsite stellt die grundlegenden Methoden bereit. coreForm stellt > zusätzliche Methoden für Formularverarbeitung und coreList für die > Anzeige von Listen bereit. Das Ganze funktioniert auch prima. > > Derzeit werden diese Klassen nur für ein einziges Projekt verwendet. Nun > möchte ich diese Klassen aber auch für andere Projekte wieder verwenden. > Meine Idee ist nun, jeweils neue abgeleitete Klassen einzurichten, in > denen dann die projektspezifisch geänderten Methoden enthalten sind. > > coreWebsite > > +----> localWebsite > > +----> coreForm > > | +----> localForm > > +----> coreList > > +----> localList > > Mein Problem ist nun, dass die in localWebsite projektspezifisch > geänderten Methoden, nicht in localForm verfügbar sind, weil localForm > ja von coreForm und nicht von localWebsite abgeleitet wird. Eine Klasse > lässt sich ja nie von zwei anderen Klassen ableiten. > > Eine erste Idee war, die projektspezifisch geänderten Methoden in > localWebsite auch in localForm zusätzlich aufzunehmen. Dies möchte ich > aber vermeiden, weil ich dann ja redundaten Code hätte und bei > Änderungen aufpassen muss, dass es nicht zu Inkonsistenzen kommt. > > Eine weitere Idee von mir war, dass ich die geänderten Methoden in > localWebsite in separaten Dateien vorhalte und innerhalb der Klassen > dann inkludiere. Aber ich weiss nicht, ob das so schlau ist. > > Gibt es für solche Probleme ein entsprechendes Pattern, dass ich nicht > kenne? > > Dein Problem ist das falsche Design. Würdest du Formulare, Listen etc. als einen (optionalen) Teil einer Webseite ansehen (part-of Beziehung), wäre es kein Problem gewesen, jede dieser Klassen zu erweitern. Als Lektüre kann ich den Abschnitt 7 [OOP I: Grundlagen] und vor allem 7.1.5 [Beziehungen] aus dem Javabuch empfehlen, das kostenlos als html Dateien zur Verfügung steht. Ist zwar für Java, aber die theoretischen Sachen sind die gleichen. [1] http://www.javabuch.de/download.html -- Mit freundlichem Gruß Martin Rozmus Tel.: +49 (0)551 4885944 Mobil.: 0177 7475196 Email: martin.rozmus at gmx.net PGP: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x0B13366C
php::bar PHP Wiki - Listenarchive