Aktionen zwischen zwei Klassen: Bester Weg?

[UnkiDunki]

Hi,

Ich habe zwei von JPanel* (panelA & panelB) abgeleitete Klassen, die ich in einer dritten Klasse (panelC) instanziiere und "verbaue".
Bei gewissen Aktionen in panelA sollen Reaktionen in panelB auftreten und andersherum.
Meine Frage ist, wie ich das am besten realisiere:

A) Benutze ich das panelC wirklich nur als "Container" für die beiden anderen panels, die ich ihre "Geschäfte" direkt zwischen sich abwickeln lasse (panelA <-> panelB) oder

B) benutze ich panelC als richtige Schnittstelle (panelA <-> panelC <-> panelB)?

Ist das ne Auslegungssache, wie ich das am besten umsetze oder gibt es prinzipiell tatsächlich nur eine einzig vernünftige Umsetzung?

Vielen Dank im Voraus

*Habe das extra nicht ins Swing-Forum geschrieben, weil das ja eigentlich einen "Allgemeinfall" darstellt.

 

[Marco13]

Ich würd sagen, dass das tendenziell egal ist, oder bestenfalls vom speziellen Zusammenhang abhängt. Wenn man die beiden Panels "schön" trennen und über eine Art "Controller"-Schnittstelle kommunizieren lassen kann, kann man das machen, aber wenn es nur eine krampfig-aufwändige Trennung um der Trennung willen ist, macht das IMHO keinen Sinn...

 

[UnkiDunki]

Erstmal danke für deine Antwort

Nun... im Prinzip ist es eine Trennung der Trennung willen der Übersichtlichkeit willen Notwendig wäre es also nicht, aber aufgrund eines gewissen Umfangs doch ratsam, wie ich finde...

 

[Marco13]

Wenn es die Übersichtlikchkeit und ggf. auch Modularität fördert, ja, natürlich. Aber (überpitzt formuliert) zwei hoch-spezielle Interfaces einzuführen "PanelAControllingInterface" und "PanelBControllingInterface", die nur vom Panel C implementiert werden, und an die jeweils anderen Panels weitergereicht werden, wäre IMHO keinem von beidem zuträglich..

 

[UnkiDunki]

Nein, da wäre der Aufwand im Vergleich zum Nutzen wirklich unangemessen größer...
Mal ein einfaches Beispiel:

panelA besitzt ein JTree mit Kategorien, panelB die dazugehörige JTable. Wird im Baum eine Kategorie ausgewählt, so sollen alle Datensätze dieser Kategorie in der Tabelle angezeigt werden. A ruft dafür z.B. eine öffentliche Methode von B auf und übergibt in dieser die ID der Kategorie. Das wäre jetzt A->B.
Beim Wahl eines Datensatzes soll im panelB alle Kategorien in einer JTable angezeigt werden, in der der Datensatz vorhanden ist. Hier könnte B eine Methode von A aufrufen mit Übergabe der ID des Datensatzes. Das wäre B->A.
Dafür müsste ich ja B A übergeben und A B, oder?
Als Alternative wäre es natürlich möglich Methoden in C aufzurufen in welcher beide Panels instanziiert wurden. Es muss dann ja nur C bei Instanziierung von A und B übergeben werden, anstatt so eine Kreuzgeschichte.

Oder wie würde das jetzt an diesem einfach Beispiel jetzt am elegantesten gehen?

 

[Marco13]

Hmja, kommt IMHO eben ein bißchen drauf an, wie stark die "semantische" Verbindung zwischen den beiden ist, und welche Rolle Panel C dabei hat (außer "ein Container zu sein"). Grundsätzlich hast du ja schon zwei Controller: Einen TreeSelectionListener und einen ... TableSelectionListener (oder wie der heißt). Im Prinzip könnten diese Listener außerhalb der jeweiligen Klasse liegen - grob im Sinne von

class PanelC
{
    void init()
    {
        panelA.addListenerToTree(treeListener);
        panelB.addListenerToTable(tableListener);
    }

    class TreeListener ...
    {
        void selectedSomething(Event event)
        {
            panelB.selectStuffFor(panelA.getSelectedThing());
        }
    }

    class TableListener ...
    {
        void selectedSomething(Event event)
        {
            panelA.selectStuffFor(panelB.getSelectedThing());
        }
    }

}

Hoffentlich ist das jetzt nicht ZU Pseudocodig ... jedenfalls wäre PanelC damit eher sowas wie ein "Controller", und PanelA und PanelB würden sich dann nicht mehr direkt kennen - was vielleicht den Vorteil hätte, dass man sie getrennt voneinander benutzen kann.... Ist aber auch nur eine spontane Idee .... ob sowas Sinn macht, musst du wissen

 

[TobiTobsen]

Ich würde da sagen das ist ne klassische Anwendung für ein Observer Pattern.

 

[Marco13]

Ich würde da sagen, dass ein TreeSelectionListener schon ein Observer IST

 

[UnkiDunki]

...
Hoffentlich ist das jetzt nicht ZU Pseudocodig ...

Ne, Quatsch. Du bringst es ja genau auf den Punkt. Danke dir dafür! Wäre auch ne gute Umsetzungsidee. Allerdings soll z.B. beim Aufruf des TreeListeners in A nicht nur in B, sondern (natürlich) auch selber in A etwas passieren. In deinem Beispiel wäre dieses ja auch umzusetzen, indem man dann im entsprechenden Listener Methoden von A aufrufen könnte oder man fügt dem A noch einen zweiten Listener hinzu, der sich nur für die internen Geschichten von A kümmert. Mhmm...
Zwar kennen sich so A und B nicht, aber getrennt voneinander nutzen möchte ich sie glaube ich sowieso nicht, daher bin ich immer noch nicht wirklich überzeugt, was jetzt genau am besten wäre. Auf jeden Fall schon mal ne gute Umsetzungsmöglichkeit von dir. Danke noch mal

Nachtrag: Die gleiche Geschichte wie du hier als Code präsentiert hast, kann ich ja auch so lösen, dass ich beiden C übergebe und bei Events Methoden in C aufgerufen werden, die wiederum Methoden aus A oder B aufrufen. Ähnliches Gebilde, aber halt der Vorteil, dass die Listener in den jeweiligen Klassen bleiben und auch dort direkt wirken können, oder?

 

[Marco13]

Hmmmmja.naja... es wäre ja AUCH wieder eine (potentiell unschöne) Verbindung, wenn beide Klassen dann PanelC "persönlich" kennen würden. Die Lösung, die ich beschrieben hatte, hat eben den Vorteil, dass man den Panels nur irgendeinen TreeListener/TableListener übergibt. Das können eigene (evlt. anonyme) Klassen sein, wie im Beispiel. Es könnte aber auch in beiden Fällen direkt PanelC sein (wenn das die entsprechenden Interfaces implementiert), oder ... prinzipiell könnte man auch sowas machen wie

PanelA implements TableListener { ... }
PanelB implements TreeListener { ... }

// In PanelC:
panelA.addTreeListener(panelB);
panelB.addTableListener(panelA);

Dann würden sich die beiden Panels zwar kennen, aber nicht "pesönlich", d.h. auch wieder nur als "irgendein Listener".

Es gibt da viele Methoden, die abhängig davon sind, wie die genaue Beziehung der Klassen untereinander ist (oder sein soll). Aber i.a. hat man schon eine wichtige... Trennung und Abstraktion, wenn eine "Übergeordnete" Instanz (in diesem Fall PanelC) dafür verantwortlich ist, den untergeordneten (d.h. PanelA und B) möglichst "unspezifische" Listener zuzuordnen. Die genaue Struktur muss man sich dann aber von Fall zu Fall überlegen.

 

[UnkiDunki]

Ok, Marco13, ich werde mich mal beiden Umsetzungsvorschlägen widmen und gucken, was mir besser gefällt. Bin natürlich offen für weitere Anregungen, aber bis hierhin bin ich schon mal recht zufrieden Danke dir!