Architektur - Zentraler Controller, viele Wrapper-Methoden

[miketech]

Hi zusammen,

ich habe mal eine Frage zur Architektur eines Programms:

Angenommen ich habe ein Programm, bestehend aus verschiedenen Komponenten für verschiedene Aufgabe. D.h. ich habe einen modularen Aufbau. Es gibt eine zentrale Komponente für die Verwaltung des ganzen Systems, der sogenannte Controller, der auch die einzelnen Komponenten instanziiert und verwaltet.

Die Idee dahinter ist, dass nun alle Komponenten immer über den Controller auf Funktionalität des Programms zugreifen können.

Ein einfaches Beispiel: Ein MP3Player bestehend aus verschiedenen Komponenten. Einer Play-Komponente, einer Komponente, die Cover runterläd usw.

Wenn nun einzelne Komponenten auf Funktionalität des Player zugreifen wollen tun sie das über den Controller.

Das Problem ist nun: Die einzelnen Komponenten kennen ja nur den Controller, zumindest war so das Konzept. D.h. wenn man die Funktionalität irgendeiner Komponente aufrufen möchte, muss man dies immer über den Controller machen. Das Ergebnis ist nun, dass der Controller viele Wrapper-Methoden hat:

public void Controller {

  public void doXY() {
     KomponenteA.doXY();
  }

  public void doYZ() {
     KomponenteB.doYZ();
  }

}

Und so muss ich das theoretisch für jede Methode jeder Komponente machen, damit die Komponenten alle Funktionalität zur Verfügung haben.


Eine andere Idee wäre, dass man die Komponenten über getter-Methoden vom Controller abfragen kann. Dann kann jede Komponente einen Aufruf folgendermaßen ausführen:

controller.getKomponenteA().doXY();

Damit spare ich mir nun die ganzen Wrapper-Methoden im Controller. Aber dann muss jede Komponente ja die anderen Komponenten kennen, was vielleicht nicht unbedingt schön ist.

Natürlich ginge auch sowas in der Art:

controller.doAction("KomponentenName", "Methodenname", Parameterliste);

....

public Controller {
...
  public void doAction(String componentName, String methodName, ArrayList<String>Parameter) {
    // Irgendwie mit Reflection oder sonst was die Methode aufrufen
  }
...
}

Aber so wirklich schön ist das ja auch nicht. Im Grunde ist mein Controller doch hier eine Fassade oder?

Gibt es hier irgendwelche Best Practices, wie man genau solche Architekturen am besten umsetzt?


Ein anderes Beispiel hierzu wäre ein Mikrokernel (Mach, Hurd usw.):

Ich habe einen Mikrokernel, der zentral die einzelnen Komponenten läd, wie z.B. Dateisystem usw. Wie sprechen nun die Komponenten miteinander? Oder können die das gar nicht? Muss alles über den Controller / Mikrokernel gehen? Hat der dann auch ewig viele Wrapper-Methoden?


Ich hoffe, es wird klar, wo das Problem liegt. Würde mich über ein paar Anregungen freuen.

Gruß

Mike

 

[Wildcard]

Bei einem solch monolitischen Machwerk wird sich jedes Analyzer Tool die virtuellen Haare raufen.
Identifizier erstmal die relevanten Schnittstellen und Punkte an denen es nötig wird das ein Modul ein anderes kennt.

 

[miketech]

Hi,

naja mir ist nicht ganz klar, wie man sonst diese modulare Architektur aufbauen kann. Beispiel MP3 Player:

Es gibt das Cover Plugin: Irgendwie muss ihm ja gesagt werden, wann es ein neues Cover laden muss. Ok das kann man über ein Event lösen, das ausgelöst wird, wenn ein Lied abgespielt wird. Aber wie klinkt sich das Plugin dann wieder in die GUI ein? Und wie kann die GUI z.B. dem Cover-Plugin sagen: Cover aktivieren / deaktivieren?

Oder beim Mikrokernel: Es gibt das Dateisystem-Modul und das Modul, dass z.B. ein neues Device erkennt. Wie sagt nun dieses Modul dem Dateisystem-Modul, dass bitte das Dateisystem erkannt werden soll?

Weiß nicht, ob das nun intern so abläuft, ist ja nur exemplarisch.

Natürlich muss nicht jede Methode eines jeden Moduls von überall aufgerufen werden können. Aber schon eine Menge. Daher ist die Frage: Hat der Controller ständig irgendwelche Wrapper-Methoden? Sollen die einzelnen Module sich überhaupt kennen dürfen? Oder ist das schon alleine schlechter Entwurf? Arbeitet man primär mit Events, die gefeuert werden?

Gibt es nicht vielleicht irgendein Pattern, was so einen Fall abdeckt? Irgendwelche Best Practices?

Gruß

Mike

Edit: Achja, eine andere Idee war schon, dass man die Methoden in einem XML-File festlegt und dann daraus dynamisch den Controller generieren lässt mit allen möglichen Wrappern. Aber das ist ja eher ein Workaround. Ich fürchte, dass einfach der Entwurf schon nicht so super ist.

 

[Wildcard]

Einmal redest du von Modulen, einmal von Plugins.
Geht es dir um ein Plugin Framework?
Wenn ja, dann musst du in jedem Fall Wochen/Monate an Vorarbeit leisten, denn hier ist Planung alles.
Ich kann dir nur raten dich näher mit der Eclipse Plugin Architektur zu beschäftigen.
Dazu gibt es sehr viel Literatur und die Jungs und Mädels konnten schon ein paar Jahre Erfahrungen sammeln :wink:

 

[miketech]

Hi,

naja das mit den Plugins ist mehr exemplarisch gemeint. Es geht mir im Grunde einfach darum, dass verschiedene Teile (Module) die Funktionalität anderer Teile (Module) verwenden wollen, aber nicht wissen, wie sie darauf zugreifen können. Nur die zentrale Einheit kennt alle Module. Ist eben die Frage, wie die Kommunikation ablaufen soll.

Aber ich schau mir mal einige Plugin-Architekturen an, danke, vielleicht hilft mir das ja weiter.

Gruß

Mike

 

[Gast]

naja, wenn plugin A auf methoden von plugin B zugreifen soll, dann wird das schon einen grund haben und plugin A sollte sehr genau wissen, was plugin B macht und wie man darauf zugreift.

generell behaupte ich mal, dass eine sehr simple plugin verwaltung mit java funktioniert, indem man ein interface plugin definiert, dass von plugins implementiert wird. und die hauptanwendung stellt eine plugin API zur verfügung, an die sich plugins anmelden können und so informationen abrufen können.

bei einem mp3 player würde die API z.b. methoden bereitstellen, um die ID3 daten des aktuellen stückes abzufragen o.ä.
und das interface plugin braucht nichts weiter als beispielsweise eine methode, um den namen des plugins abzufragen.