Zwei Panels, die sich gegenseitig 'notifyn' sollen

[Mujahiddin]

Guten Tag allerseits

Ein JFrame. Zwei Panels.
Ein Panel mit Buttons / CheckBoxes (Tools)
Ein Kartenpanel, wo man Städte einfügen / verbinden kann.

Problem:
> Auf dem BoxPanel kann man anhaken, was man auf dem Kartenpanel vorhat, von wegen 'Verbinden' oder 'Erzeugen' oder 'Karte löschen', etc.
> Auf dem KartenPanel kann man per Klick eben diese Sachen machen.
Dazu müssen sie aber voneinander wissen... Und zwar muss Kartenpanel BoxPanel fragen, was angehakt ist.
Wenn auf BoxPanel 'Karte löschen' gedrückt wird, muss er das dem KartenPanel berichten. Ich will aber nicht irgendwelche Methoden einbauen, von wegen 'setBoxPanel(BoxPanel pnl);' oder beim BoxPanel 'setMapPanel(MapPanel pnl);'
Klar wäre das die einfachste Variante, aber gibt es denn keine andere? Ich finde, das sieht relativ eklig aus, wenn jedes Objekt Zugriff auf jedes Objekt hat :/

Hat jemand ne bessere Idee oder muss ich wohl in den mehr oder weniger sauren Apfel beißen?

Mit freundlichen Grüßen!

 

[Guybrush Threepwood]

I.) Ich denke, das ist ein Fall für das Observer-Pattern. Wie genau das bei den beiden Panels zu realisieren ist, kann ich Dir aber nicht sagen. Ich denke, dass es das Beste wäre, wenn sich die Panels nicht direkt gegenseitig "notifien", sondern wenn eine dritte Instanz vermittelt. Die Panels sollten von Observable erben (extends Observable), die dritte Instanz als Beobachter fungieren (implements Observer) und alles steuern.

II.) Alternativ: Die Panels haben Referenzen aufeinander und können über Interfaces direkt interagieren.

III.) 2. Alternative: Die beiden Panels befinden sich in einer dritten Klasse, die auch die Logik enthält und die Zugriff auf beide Panels mit ihren Eigenschaften hat.

 

[Mujahiddin]

Hallo LeChuckFeind

Ich habe schon BtnPanel extends JPanel... Ich kann das doch nicht von zwei Sachen erben lassen, oder?

Ist das mit der dritten Klasse nicht genau das mit Observer?

 

[kay73]

Wenn Du Dich nach dem Model/View/Controler Prinzip richten würdest, wäre das JFrame der View und hätte eine Referenz auf ein Spielzustandsobjekt (Model), die es via getter für die Kindkomponenten exportiert. Dazu gibt es eine Controllerklasse, die die Spiellogik abbildet. Das JFrame würde einen Listener auf die Checkbox implementieren, das Model beim Event via Controller aktualisieren und eine Update/Refresh feuern. Alle Kindkomponenten würden sich dann neu zeichnen und den Zustand abbilden, den sie aus dem Model lesen können.

 

[Guybrush Threepwood]

MVC wäre sicherlich der sauberste Weg. Wenn Du auf die Schnelle eine Lösung suchst, dann wäre es eine Möglichkeit, dass Dein KartenPanel ein selbstdefiniertes Interface implementiert und eine Referenz an das BoxPanel weitergibt. Wenn sich im BoxPanel eine Einstellung ändert, dann ruft es direkt die entsprechende Funktion im KartenPanel auf.

 

[Mujahiddin]

Das mit dem Interface klingt für mich am ansprechendsten... Ich weiß aber nicht, wie ich das bewerkstelligen soll.

Also ein Interface mit ner Methode 'buttonClicked', aber wie ordne ich an, dass das BtnPnl genau auf das Interface des MapPnls die Änderung schickt?

So?

public interface Notifyable
{
   void map_deleted();
   ...
}


public class MapPnl extends JPanel implements Notifyable

...
public void map_deleted()
{
   deleteMap();
}
...

Was müsste dann ButtonPanel bei ButtonClick machen, damit genau MapPanel darauf reagiert?

Irgendwie sowas würde ich mir vorstellen:
public void actionPerformed(ActionEvent evt)
{
Notifyable.map_deleted();
}

aber das wäre ja vollkommener Unsinn, würd nix bringen.
Wie sagt BtnPnl MapPnl, dass der Button geklickt wurde, ohne direkt auf MapPnl zu verweisen, sondern bestenfalls über das Interface?
Danke im Voraus

 

[Guybrush Threepwood]

Ok, also Du brauchst das Interface:

public interface NotifyInterface{
           public void deleteMap();
}

Als nächstes muss - wie richtig beschrieben - das MapPanel das Interface implementieren:

public class MapPnl extends JPanel implements NotifyInterface
 
...
public void deletedMap()
{
   //hier die entsprechende Funktionalität
}

Jetzt muss auch Dein ButtonPanel von der Schnittstelle mitkriegen:

public class ButtonPanel extends JPanel{
    public ButtonPanel(final NotifyInterface nInterface){
    ......

               deleteButton.addActionListener(new ActionListener() {
			public void actionPerformed(ActionEvent e) {
                               nInterface.deleteMap();
			}
		});

    .....
    }



}

Letzter Schritt: Dein ButtonPanel muss etwas von MapPanel mitbekommen, z. B. dort, wo Du es instanzierst:

MapPanel mPanel = new MapPanel();
ButtonPanel bPanel = new ButtonPanel(mPanel);

Auf diese Weise übergibst Du lediglich die Schnittstelle. Wenn das nicht möglich ist, dann musst Du eine andere Lösung suchen, z. B. über das Observer-Pattern oder indem eine dritte Instanz Kenntnis der beiden Objekte hat und zwischen den beiden vermittelt.

Vielleicht noch ein ganz abgefahrener weiterer Weg: Das ButtonPanel schreibt in die Preferences und das MapPanel hat einen PreferencesListener und "beobachtet", ob sich dort etwas verändert. Das wäre aber echt freaky, würde aber funktionieren.

Viele Grüße!

 

[Mujahiddin]

Ich bedanke mich herzlichst für deine Hilfe!

Ich habe einfach eine Klasse 'MapEvent' mit einer Enumeration wie 'MAP_DELETED, BOX1_CLICKED' etc. erstellt. Ein Objekt dieser Klasse wird dann eben einen dieser "Parameter" (?) im Konstruktor zwangsweise definiert bekommen. Das BtnPanel schickt dann an das MapPnl dieses neue Objekt des MapEvent, woraufhin dieser per switch abgeklärt, was gemacht werden soll.

So finde ich, dass es wirklich gelungen ist... Wobei ich mir nicht bewusst bin, wie das mit den Preferences gehen soll... Wenn du mal Lust hast, kannst du das ja genauer erklären, muss aber nicht unbedingt sein.

Das mit Observer ging leider nicht, weil meine Panels nicht von 2 Klassen erben können.

Ansonsten hoffe ich, dass man sich nochmal sieht.

 

[Guybrush Threepwood]

Preferences (Preferences (Java Platform SE 6)) ist eine tolle Klasse um Einstellungen zu speichern. Auf Windows wird dazu in die Registry geschrieben, aber für Dich auf Programmebene ist das extrem einfach und Du musst Dich nicht um die Details kümmern. Man kann so sehr gut programmweite Einstellungen ablegen und dauerhaft verfügbar machen.

Wenn Du jetzt solche Sachen hast, wie Darstellungseigenschaften in der GUI, dann kann man das natürlich sehr gut dauerhaft ablegen, damit ein User nicht immer wieder alles neu einstellen muss. Gleichermaßen kann man von anderer Stelle darauf "lauschen", ob sich an den Einstellungen etwas verändert und dann entsprechen reagieren. Im Grunde ist hier das Observer-Pattern am Werk, so wie bei allen Listenern. Du brauchst einfach nur ein Preferences-Objekt und lässt es beobachten:

Preferences prefs = userNodeForPackage(MeineKlasse.class);
prefs.addPreferenceChangeListener(new PreferenceChangeListener() {
          public void preferenceChange(PreferenceChangeEvent evt) {
                 machIrgendetwas();
          }
     }
});

Eine einfache und unkomplizierte Möglichkeit, aber man muss überlegen, ob der Anwendungsfall passt. Das kann bei solchen GUI-Sachen wie bei Dir gut sein. Wie gesagt, es hängt vom konkreten Fall ab.

Viele Grüße,
Guybrush

 

[Mujahiddin]

Verstehe Sowas ähnliches hatte ich auch schon mal gesucht...
Aber ich glaube, bei meinem Fall wäre das zu weit hergeholt , ich hab ja nur zwei-drei Checkboxen, die voraussichtlich immer umgeklickt werden ^^
Aber dennoch, bestimmt ist sowas hilfreich!
Ich glaube, das gehört jetzt nicht hierher, aber könnte man evtl auch eine Art .cfg-Datei auslesen / erstellen, die der User selber 'modifizieren' kann? Über Serializable kommen ja irgendwelche chinesischen Zeichen, aber das müsste doch irgendwie gehen, oder?

 

[Guybrush Threepwood]

Sorry, da bin ich überfragt (in punkto cfg).

 

[Mujahiddin]

Nicht schlimm.

P.S. Monkey Island ist ein cooles Spiel.. ^^

 

[Guybrush Threepwood]

P.S. Monkey Island ist ein cooles Spiel.. ^^

Jaaa! Und es gibt eine Neuauflage, wo man zwischen der alten und einer neuen Grafik umschalten kann. (LucasArts.com | The Secret of Monkey Island: Special Edition)

... die gute alte Zeit!