[nove]

Wie würdert ihr folgende Problematik lösen:

Ich stehe vor der aufgabe, daß ich eine GUI bauen sollte die auf grundsätzlich gleiche Datenobjekte zugreifft die sich nur in ein paar Punkten unterscheiden.

Um es klarer zu sagen:

Es gibt ne Tabelle in der Datenbank die grundsätzliche Partnerdaten enthält.
Ein Partner kann aber ein Kunde, Lieferant oder Personal sein. Hierzu gibt es
noch weitere 3 Tabellen. Aus diesen Tabellen entstehen z.B. in einer CustomerFactory die CustomerObjekte die alle relevanten Daten für den Kunden enthalten. Gleiches geschieht mit Lieferanten und Personal.

Jetzt möchte ich aber nicht für die Dartstellung 3 GUIs bauen sondern wenn
möglich nur eine PartnerGUI bauen die aber auf die Partnerart reagiert und
dieses dann dementsprechend darstellt.

Hat da jemand ne gute Idee.

[ehli75]

du hast ja bestimmt für die einzelnen Partner (Kunde, Lieferant oder Personal) unterschiedliche Klassen !? Ich würde da in der "Haupt-GUI" einen Bereich vorsehen, der für die Anzeige der Partnerdaten zuständig ist ... aber keine GUI-Objekte ansich enthält. Und dort hinein lädst du dann via Reflexion ein spezielles Partner-GUI-Panel. d.h. du müsstest für jeden möglichen Partner eine GUI-Klasse bauen, die ein bestimmtes Interface implementiert ... z.B.:

PHP-Code:

public interface PartnerGui {
   public JPanel getPartnerPanel( Hashtable data );
} 


Die Daten würde ich in eine Hashtable packen, damit jede PartnerGUI-Implementierung die selber rausholen kann - die wissen das ja selber am Besten. Die Daten selber kommen ja aus deiner Applikationsschicht (als guter Java-Programmierer hast du doch hoffentlich die GUI von der Applikation getrennt ;o) ) ... und da packst du in deinen einzelnen Partnerklassen die Daten in die Hashtable rein ... die "Haupt-GUI" reicht diese dann nur die Partner-GUI's durch.

... oder ist das die Lösung, die du gerade vermeiden wolltest ??

Michael

[nove]

nee is klar..

Die Daten sind eine völlig getrennte Geschichte. Mir geht es Grundsätzlich Darum EINEN InternalFrame zu haben bei dem ich z.B. durch überladen des Konstruktors verschiedene GUIs bekomme oder Panels dynamisch nachlade (d.h. diese als eigenständige Klasse bereithalte). Es geht hier eigentlich um eine reine Designentscheidung um später nicht
in die Debug-Hölle zu kommen.

[sparrow]

Ich würde den plumpen weg gehen.
Du sagst ja, die GUI unterscheidet sich kaum.
Die Unterschiede würde ich in getrennten Methoden zeichnen lassen, und das was gleich ist in einer die immer aufgerufen wird.

Du könntest dann zum Beispiel die Methode showCustomer aufrufen, statt den Konstruktor zu überschreiben.
new frame.showCustomer();