Anwendungs-Design (Plugin-Architektur)

[AlArenal]

Ich hab mal ne eher allgeime Problemstellung.

Ich habe eine selbstentwickelte Anwendung, die könnt ihr euch vielleicht ähnlich wie Visio vorstellen. Ich habe also grafische Objekte, die ich per Drag&Drop in eine Arbeitsfläche ziehen und dort verbinden kann.

Jedes dieser grafischen Objekte hat eine eigene Klasse als Grundlage, das Ganze kann ich derzeit in XML speichern und laden, später kommt noch die Anbindung an ein System hinzu, um die Objekte mit Daten aus dem System zu verknüpfen. Nun wird es analog zu Visio verschiedene Bibliotheken mit grafischen Objekten geben.

Soweit sogut.

Problem:
Beim Laden/Speichern und Sachen wie dem Anzeigen von kontekxt-sensitiven Popup-Menüs müss ich ja immer die Objektliste des Dokuments durchlaufen und mit einem ellenlangen if(instanceof)-else-Zweig spreche ich die Methoden der verschiedenen Klassen an.

Nun möchte ich das Ganze nach Möglichkeit dahingehend entzerren, dass irgendwo in einer Liste oder ähnlichem eine Zuordnung zwischen Klasse und Methoden festgelegt werden kann, die in den verschiedenen Fällen aufgerufen werden sollen, nach Möglichkeit so, dass ich nicht für jedes neue grafische Objekt überall den if-else-Zwei erweitern muss. Am elegantesten wäre eine Art Plugin-Architektur, so dass eine neue Bibliothek einzeln verschickt und eingefügt werden kann, anstatt da jeweils ne kundenspezifische Version zu der kompletten Anwendung zu backen.

Ich dachte mir, sowas sei vielleicht über Reflection machbar, aber mir fehlt irgendwie noch die kritische Masse im Kopf, ehe es "klick" macht. Vielleicht hat von euch ja mal ne Idee?

 

[Beni]

Interfaces ?

Ich hab vor einigen Wochen was ähnliches geschrieben, und kann da mit gutem Gewissen sowas in diese Richtung empfehlen:

public interface GraphicObject{
  public void paint( Graphics g );

  public GraphicFactory getOrigin(); // woher dieses Objekt kommt

  public void write( XMLWriter writer );  // was auch immer der XML-Writer sein soll...

  public void read( XMLReader reader ); // wie auch immer der XML-Reader implementiert ist...
}

Und vielleicht noch eine zentrale Klasse, bei der man Factories anmelden kann:

public interface GraphicFactory{
  public GraphigObject createNewInstance();

  public ContextMenuInformation getContextMenuInformation( GraphicObject obj );
}

public class GraphicCenter{
  public void register( String name, GraphicFactory factory ){ ... }
}

Es geht nur um eines: die "Plugins" können ihre neuen Features irgendwo registrieren, und dein Progi klappert dann diese Listen ab. Da es Interfaces sind, muss man nicht zwischen verschiedenen Klassen unterscheiden.
Bei meinem Programm, das sehr auf Plugins ausgelegt ist, sind mindestens 25% aller *.java-Dateien Interfaces...

 

[KSG9|sebastian]

ich hoffe mal das ich dich richtig verstanden hab..!

wie wär es mit vererbung ?
du machst eine Superklasse, von mir aus "Koerper" und dann erzeugst du die Objekte mit

Koerper K = new Schrank()

und dann kannst du mit K.methodeABC() ja immer die gleiche Methode aufrufen und brauchst nicht für jeden neuen Körper alles neu machen!

 

[AlArenal]

@beni:

Ich mache es im Grunde ähnlich. Das Dokument hat eine Methode zum Laden und eine zum Speichern von XML, kann sich also selbst in XML (de-)serialisieren. Dazu läuft es intern durch die Liste aller Objekte, stellt fest welche Klasse es ist, macht nen cast und ruft dann die XML-Laden/-Speichern-Methode in dem jeweiligen Objekt auf. Dazu implementieren diese auch ein Interface, welches die beiden Methoden definiert.

Da könnte ich im Grunde per Reflection fragen ob das Object das Interface implementiert und wenn ja, ebenfalls über Reflection die passende Methode aufrufen? Das sollte doch eigentlich funzen, oder? Damit hätte ich den Part schonmal abgefrühstückt..

Das mit der Factory muss ich mir mal durch den Kopf gehen lassen und Bücher wälzen, damit mir das prinzipiell etwas klarer wird. Hölle, ich muss mal was essen...


@KSG9|plak:

Die Objekte kommen im Grunde von einer Superklasse, aber ich habe auch noch die Verbindungen und andere Sachen in dem Dokument, kann also nicht stillschweigend davon ausgehen, dass alles im Dokument von derselben Klasse abgeleitet ist. Zumal ich nie weiß, was mein Chef sich als nächstes ausdenkt, von daher versuche ich gleich etwas variabler zu sein... was mal mehr und mal weniger gut gelingt

 

[AlArenal]

Laden/Speichern über Reflection funzt wie geplant prima. Allerdings muss ich fürs Laden noch ne Hashtable von Hand pflegen, die eine Zuordnung zwischen einem XML-Tag und der Klasse des zugehörigen Objekts vornimmt, weil ich ja schon wissen muss welche Klasse ich brauche um ein Objekt zu erzeugen.

Das wäre f+ür später vielleicht noch ein Ansatzpunkt für einen Plugin-Mechanismus, diese Hashtable ebenfalls dynamisch zu erzeugen...