Klassenhierarchie

[grisu]

Hallo zusammen,


Ich habe folgende Objekte, die alle von einem gemeinsamen Grundobjekt erben:
Entity, State, Action, EntitySet, View

- Entity kann andere Entities, States, und Actions aufnehmen
- EntitySet kann Entities und EntitySets aufnehmen
- View kann States aufnehmen

Wie bekomm ich das in eine sinnvolle Struktur, ohne dass ich Sachen zweimal implementieren muss?
Mit Vererbung komm ich hier nicht weit.

Folgende Lösungen fallen mir ein:
Ich definiere einen ObjectContainer, der als Container für das BaseObject fungiert. Nachteil: Ich muss ständig casten, und kann auch nicht verhindern, dass jemand Unfug treibt

Oder ich definiere Container: EntityContainer, StateContainer, ActionContainer, EntitySetContainer.
Diese Container könnte man als Komponenten der Hauptklassen einsetzen. Die Hauptklasse selbst implementiert ebenfalls die benötigten Schnittstellen, leitet die Aufrufe dann aber an die Komponente weiter.
Diese Version gefällt mir grade ganz gut... das hätte dann was von einem Decorator...

Sonstige Ideen?

Danke und lg
Chris

 

[maki]

Vererbung von Implementierung wird meist überbewertet und noch öfter missbraucht.

Versuche es mal mit gemeinsamen Interfaces, Komposition und zB. dem Composite Pattern (ist nicht dasselbe wie Komposition).

 

[grisu]

Hi,

könntest du das etwas genauer erklären?

Was meinst du mit gemeinsamen Interfaces?
Das würde eh in Richtung meiner zweiten Idee gehen oder?

 

[maki]

"Genauer erklären" ist das Stichwort

Wer erbt von wem was genau und wozu?

 

[grisu]

Hm...

Die Objekte erben untereinander garnicht. Die erben alle von einem gemeinsamen BaseObject (das aber hier keine Rolle spielt).

Mir gehts um die spezifischen Funktionen, andere Objekte aufzunehmen und zu handlen. (wer was aufnehmen kann siehe erster Post).
Mit Vererbung lässt sich das nicht lösen - ich würde immer irgendwo Funktionen doppelt implementieren müssen.

Deswegen mein zweiter Vorschlag:

class EntityContainer implements IEntityContainer { ... }
class ActionContainer implements IActionContainer { ... }

class Entity implements IEntityContainer, IActionContainer
{

    private IActionContainer actionContainer;

    private void addAction ( ... )
    {
        this.actionContainer.addAction ( ...);
    }

    // usw.
}

 

[schalentier]

Erklaer mal genauer, welche Funktionen du doppelst implementierst.

 

[grisu]

Vielleicht war der Post etwas verwirrend. Sorry.

Mir gings darum:

- Entity kann andere Entities, States, und Actions aufnehmen
- EntitySet kann Entities und EntitySets aufnehmen
- View kann States aufnehmen

Ich brauche also in jeder Klasse Methoden zur Verwaltung dieser Objekte.
Ich wollte das erst mit Vererbung lösen, aber wie? Entity kann nicht von EntitySet erben, EntitySet auch nicht von Entity usw. Ich bekomme, um diese Anforderungen zu erfüllen, keine sinnvolle Vererbungsstruktur zusammen.

Mein Code im letzten Post war mehr oder weniger mein Vorschlag, wie man das lösen könnte: Die Klassen implementieren die benötigten Interfaces, und leiten die Aufrufe an eine Komponente weiter, die sich um die Verwaltung kümmert.
Habs jetzt auch so umgesetzt, funktioniert recht gut (einziger Nachteil, den ich sehe, ist dass ich recht viel "leere" Methoden hab, die eben die Aufrufe nur weiterleiten. Aber damit kann ich leben )

Jo und eigentlich wollt ich nur wissen, obs dafür evtl. eine elegantere Möglichkeit gibt

 

[schalentier]

Mh, also ich denke du machst es dir ziemlich kompliziert - letztlich hast du jetzt die Funktionalitaet zum Hinzufuegen eines Elements zu einer Liste irgendwie ausgelagert. Dazu bringst du mehrere Interfaces und jede Menge Delegate-Methoden zusaetzlich ins Spiel. Der Vorteil ist, du kannst dieses Verhalten nun zentral ändern. Aber wozu?

DRY (dont repeat yourself) ist zwar richtig und sehr wichtig, aber ich glaube (zumindest mit Java) muss man solche Sachen und die meisten Design Patterns einfach ausprogrammieren.

Wenn du dir die Tipparbeit sparen oder erleichtern willst (nur wenns WIRKLICH viel Tipparbeit wäre), ist evtl. ein (aktiver oder passiver) Codegenerator geeignet - oder nimmst die Live Templates Funktion aus deiner IDE.

 

[Wildcard]

EMF ist hier ideal.

Mir gings darum:

- Entity kann andere Entities, States, und Actions aufnehmen
- EntitySet kann Entities und EntitySets aufnehmen
- View kann States aufnehmen

Du brauchst das nur 1:1 im Ecore Editor so anzulegen und dann wird daraus der fertige Code generiert.