Designproblem: Factory organisieren

[SnooP]

Moin... hab gerade nen kleines Designproblem und komm nicht so richtig hinter die "richtige" Lösung, bzw. weiß nicht, ob mein geplantes Vorgehen jetzt besonders hübsch ist oder nicht

Folgende Sache: Ich habe eine Factoryklasse die verschiedene Produkte (16) eines Obertyps erzeugen soll. Dazu ists aber erforderlich, dass der Benutzer einige Daten eingibt, die zu erzeugenden Objekte also zunächst konfiguriert. Die Auswahl derjenigen Einstellungen die der Nutzer machen kann ist wiederum abhängig vom Typ zweier Objekte.

Jetzt hab ich in der Factory eine Methode erstellt, die anhand dieser zwei Objekte schonmal ein JPanel erstellt (Fallunterscheidung mitHilfe von instanceof über die beiden Objekte)... dieses Panel wird dann später in einem Wizard dargestellt und unterscheidet sich halt jedes Mal etwas...

soweit so gut - jetzt hab ich das Problem, dass ich zu diesem Zeitpunkt anhand der beiden übergebenen Objekte schon weiß, welcher Typ das später werden muss, den ich mit der Factory erzeugen will. Momentane Idee ist, dass ich an der Stelle schonmal den Typ erzeuge und in einem Feld "currentProduct" zwischenspeichere (in der factory) - wenn ich später im Panel alle Angaben gemacht hab und auf "DONE" drücke, kann ich mit den Daten des Panels das Produkt konkretisieren und in der eigentlichen create-Methode zurückgeben.
Jetzt ists aber so, dass die Datenfelder in den Panels natürlich recht unterschiedlich sind - die Idee war jetzt, dass ich ne JavaBean baue, die ich der eigentlichen createMethode der Factory übergebe, diese das temporär gespeicherte Produkt schnappt, einer im Produkt vorhandenen setConfig-Methode die Bean übergebe und letztlich das Endprodukt zurückgebe...

Der Umweg über die Bean deswegen, weil ich ansonsten wieder unterschiedliche create-Methoden für den jeweiligen Typ hätte und diese auch irgendwo abhängig vom Typ des Endprodukts aufrufen müsste... allerdings geb ich zu, dass dann die Konfiguration des Produkts im Produkt selbst nach seiner eigentlichen Erzeugung stattfindet... nicht ganz im Sinne des Erfinders der Factory oder?
Andererseits kann dann das Produkt selbst entscheiden in seiner jeweiligen Variante der setConfig-Methode, welche Daten sie aus der Bean auslesen möchte.

Ne andere Möglichkeit wäre sich den Endtyp irgendwie als Konstante zu speichern - allerdings muss dann am Ende schon wieder ne Fallunterscheidung anhand 16 unterschiedlicher Konstanten stattfinden, was auch wieder blöd wäre...
Zudem wäre es durchaus möglich, dass irgendwann noch weitere Produkte hinzukommen - d.h. man müsste immer auch noch die Konstantensammlung erweitern etc...
Auch könnte ich natürlich die Fallunterscheidung die zur jeweiligen Auswahl und Erzeugung des Panels geführt hat, einfach später für die Erzeugung des Endprodukts nochmal wiederholen... aber 16 instanceofs in einer Methode per if-else sieht schon einmal sehr bescheuert aus ..

Irgendwie gefällt mir das alles nicht so - hat nicht evtl. jemand nen Tip für mich, falls man überhaupt durch das sehr abstrakte Gelaber von oben durchsteigt?

P.S. 2nd-Question - was würdet ihr davon halten, wenn eine Factory-Methode nicht nur das Produkt selbst erstellt, sondern auch gleich schon in die relevanten Datenstrukturen einträgt, die es am Ende verwalten sollen. Sauber oder eher Unsauber?

 

[Guest]

Ich weiss nicht, ob ich Dich richtig verstanden habe, aber ich sehe es so

- Du weisst am Anfang was erzeugt wird (irgendeine Konstante)
- Anhand dieser Information erzeugst Du die Panels
- Die Panels liefern am Ende ein Produkt (alle sind wahrscheinlich von einem Basistypen abgeleitet, oder?)

Der Aufruf an die Factory sieht dann ungefähr so aus

Factory.createProdukt(typ, produktdaten)

Jetzt willst Du verhindern, dass in dieser Methode folgendes auftaucht

if(typ == A)
  return createA(daten);
else if(typ == B)
  return createB(daten);
else if(typ == C)
  return createC(daten);
...

Stimmt es soweit? ???:L

 

[SnooP]

Ja soweit ists in etwa richtig ... und die Produkte sind natürlich von einem Obertyp abgeleitet, bzw. implementieren ein entsprechendes Interface.

Die produktdaten kapsel ich jetzt in ne JavaBean - und die Konstanten möcht ich mir damit ersparen, dass ich die bean dem vorher bereits temporär erzeugten Produkt mit in die setConfig-Methode schmeiße und dann das Endprodukt liefer.

Frage ist jetzt, obs ne coole Alternative gibt ...

Ne andere Möglichkeit wäre ja noch, unterschiedliche Panel-Klassen zu nutzen (die alle von JPanel erben) und diese zu instanzieren in der Auswahlmethode, die die Panels erzeugt. Dort könnte dann nach Eingabe aller Daten eine konkrete create-Methode aufgerufen werden...
Nachteil hierbei ist, dass ich View und Controller vermische - ich wollte die GUI so blöd wie möglich lassen.

 

[Guest]

Ich würde es vielleicht so versuchen.

- An einer zentralen Stelle ein Art Registry für die Wizards initialisieren.
- Die Registrierung erfolgt mit drei Angaben: WizardUI, WizardController, Metadaten (für die Auswahl am Anfang)

WizardUI ist die Benutzeroberfläche, WizardCtl der Controller, der auch für das Erstellen der Produkt-Instanz
zuständig ist. Als Metadaten könnte ich mir paar Angaben vorstellen, die Du am Anfang zur Auswahl anzeigst.
Die Registry stellt die verfügbaren Wizards zur Verfügung (anhand der Metadaten) und initialisiert sie.

Vorteil wäre, dass jedes Produktwizard als ein Modul registriert oder entfernt werden kann, ohne bestehenden
Code zu ändern.
Du könntest dann die einzelnen "ProduktWizards" extern (z.B. über eine XML Datei) konfigurieren oder irgendwo
beim Initialisieren der Registry-Klasse.

<wizards>
  <wizard id="whatever">
    ...
    <view class="..." />
    <controller class="..." />
  </wizard>
</wizards>

Das wäre eine Art Plugin-Model mit klaren Spielregeln.

Kann mich einer einweisen? :bae::bahnhof::autsch:

 

[SnooP]

Puh ja ... das halte ich jetzt aber doch für etwas overkill für meine Zwecke - zumal ich mit der GUI-Programmierung nix zu tun hab, das wäre höchstens was, was ich dem zuständigen Programmierer erzählen könnte...

ich glaube ich werde meine Lösung mit der javabean durchziehen - halte ich momentan für die netteste Lösung. Da verschicke ich dann zwar etwas Redundanz, aber nunja - an der Stelle noch zu vertreten, da lediglich gui-interaktion.

Die andere Frage ist die Geschichte mit den Seiteneffekten in einer Factory-Methode... sollte man die factory-Methode wirklich nur aufs Erstellen des Produkts beschränken oder aber kann ich das Produkt dort gleichzeitig schon in die gewünschten Datenstrukturen eintragen.
Wenn ich das nicht mache, muss das eine zentrale Controller-Klasse erledigen, die zunächst das Produkt erzeugt und danach dann per add irgendwo registriert... hört sich für mich wenn ichs so schreibe schon irgendwie sauberer an