Grundsatzfrage zu Decorator-Pattern

[Pahlkenberg]

Hallo ich hätte da mal eine grundsätzliche Frage zum Decorator-Pattern. Ich möchte eine Klasse Konto so dekorieren, dass ein zusätzliches Feld "private int customerId" (mit Gettern und Settern) vorhanden ist.
Jetzt heißt es überall, der Dekorierer (z.B. in meinem Fall "KontoPlusCustomerId" mit Instanzvariable "Konto konto"), solle vom Typ her dem zu dekorierenden Objekt entsprechen und auch von außen als solches behandelt werden. Also würde ich "KontoPlusCustomerId extends Konto" implementieren. Jetzt ergibt sich da meinem Verständnis nach aber ein Problem.
Wie soll man denn die Methode "getCustomerId()" aufrufen, wenn man das Objekt als Konto initialisiert und rumreicht. Das lässt einem der Compiler doch nicht durchgehen, weil "Konto" das garnicht kennt.
Soll man da jedes Mal, einen Typcast vornehmen? Und wenn ja, wieso soll man das ganze Objekt dann überhaupt als Konto deklarieren, wenn der einzige Zweck ja darin besteht, diese zusätliche Id abzuspeichern?

 

[bygones]

Beim Decorator sollte es sich auch wirklich nur um eine dekorieren bestehender Funktionalitaet handeln und nicht das hinzufuegen neuer.

D.h. dein decorator implementiert das selbe Interface und bekommt als "Basis" ein Objekt des selben Interfaces.

Die Implementierungen bestehen dann aus der dekoration der "Basis".

D.h. du muesstest deine customerID in irgendeiner Form intern nur behandlen - wenn das nicht geht, so ist es eine neue, erweiterte Klasse, aber kein Decorator

 

[shortys]

Hallo,
was willst du denn fachlich wiedergeben - dass der Kunde ein Konto besitzt?

 

[Pahlkenberg]

Nein es ist so, dass meine "Konto"-Klasse, die in den Beans im Frontend benutzt wird, als Instanz einen Customer hat.
Bei der Erzeugung der Konten im Backend wird eine KontoFactory angeschmissen, die aber keinen Zugriff auf die KundenDaten hat und somit kann der Kunde noch nicht eingepflanzt werden. Es wird also ein Objekt erzeugt, dass alle Konto-Informationen enthält (außer dem Kunden) plus einer Id, die man eindeutig dem Kunden zuordnen kann. Diese customerId haben meine fertigen Konten aber eigentlich garnicht, weil eben wie gesagt das Ganze Kundenobjekt dann drin sein soll.
Naja das so erzeugte Objekt wird dann an meine Dao übergeben, die wiederrum den richtigen Kunden in das Konto einsetzt anhand der Id und diese ist ab dann wertlos. Meine Factory erzeugt also momentan ein KontoPlusCustomerId-Objekt. Und meine Kollegin hat mir empfohlen, ob ich nicht mal das Decorator-Pattern durchlesen und anwenden will.
Wenn es mit Decorator ungünstig ist, könnt ihr mir dann vielleicht eine andere Vorgehensweise empfehlen? Vielen Dank

 

[bygones]

wueder da eher Delegation nehmen

public class KontoCustomer {
  private Konto konto;
  private int number;

  // benoetigte Methoden
}

dein Konto hat ja keine Schnittstelle, die du beim Decorator hernimmst. Wenn es ein einfaches Bean ist, so wuerde ich Delegation eher nehmen.

 

[Pahlkenberg]

Ok danke!

 

[André Uhres]

Also würde ich "KontoPlusCustomerId extends Konto" implementieren.

Beim Decorator Pattern müssen beide, der Decorator und die zu dekorierende Komponente, entweder von derselben (abstrakten) Basisklasse abgeleitet werden oder dasselbe Interface implementieren. Das ist mit "KontoPlusCustomerId extends Konto" nicht zu verwirklichen. Zudem sollte der Client Code sich nur auf die gemeinsame Basisklasse oder das gemeinsame Interface stützen. Aus beiden Gründen ist das Decorator Pattern in Deinen Fall keine Hilfe.

Gruß,
André