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