Zugriffsproblem

[dable]

Hallo,

ich hab eine Klasse ScoutPanel in welcher sich unter anderem 2 weitere Panels (jeweils eine eigene Klasse) befinden (PanelA, PanelB). In PanelA wird eine Tabelle (mit Hilfe eines TableModel) dargestellt. Jetzt möchte ich gerne in PanelB auf Daten aus dieser Tabelle zugreifen.
Könnt ihr mir sagen, wie ich da am einfachsten rankomme ohne das bestehende Klassenkonzept zu zerstören?

 

[SlaterB]

ScoutPanel erstellt PanelA und B, fragt dann das TableModel von A ab und übergibt es an B per Methoden,
B speichert sich das Model in einem Klassenattribut

 

[hdi]

Naja ich find Slaters Vorschlag zwar durchaus "richtig".

Aber wenn man anfängt Eigenschaften einer Klasse in eine andere zu "exportieren", ist das schon extrem speziell und unflexibel gelöst.

Wenn PanelB nur lesenden Zugriff auf Daten von PanelA braucht, würde ich
das ganze eher über eine dritte, neutrale Stelle regeln.
(eigentlich kannste das auch machen wenn er schreibenden Zugriff braucht)
Bastel dir ein allgemeines Konstrukt (Interface), mach daraus
deine spezielle Implementierung (TabellenDatenKonstruktImpl oder so), und
lass die 2 Panels einfach darüber kommunizieren.

Die Implementierung enthält dann einfach nur die interessanten Daten und eine
set sowie get Methode.

Damit kannst du das ganze schnell austauschen oder wegwerfen, PanelB ist
dann nicht mehr an PanelA gebunden, sondern besitzt einfach die Funktionalität
sich Daten aus einer Schnittstelle zu holen, falls es welche gibt.
(Völlig egal woher die kommen)
Und PanelA kann Daten an diese Stelle leiten, falls erwünscht.

Man kann natürlich auch argumentieren dass das "übertrieben" ist, wie gesagt was
Slater sagt funktioniert natürlich und ist wesentlich schneller und leichter vollbracht.

Aber da du extra betont hast "ohne das bestehende Klassenkonzept zu zerstören",
dachte ich ich geb dir vllt mal ne etwas allgemeinere Herangehensweise.
Wobei Slaters Vorschlag deine Klassen nicht "zerstört", aber es macht sie unflexibler.

Wenn du genau weisst dass du sie nicht flexibel brauchst, weil sich eh nix dran ändert,
dann mach es so wie Slater dir gesagt hat!

 

[dable]

@SlaterB: danke für den Vorschlag. Wenn B das Model in einem Klassenattribut speichert und danach A Daten im TableModel verändert, wird dann auch das Klassenattribut von B angepasst?

@hdi: flexibel wäre schon besser, das ganze Programm ist sowieso schon recht unübersichtlich. Ich weiß nicht, ob ich deinen Vorschlag richtig verstanden habe. Ich soll ein Interface schreiben, welches von beiden Tabs implementiert wird und eine set und eine get Methode beinhaltet. Wo speichert das Interface denn dann die Daten? In einer privaten statischen Eigenschaft? Ich habe irgendwie noch nicht so den Überblick...

 

[SlaterB]

@hdi:
hehe

@dable:
ja bzw. ausprobieren!

 

[dable]

Also SlaterB's Vorschlag funktioniert jetzt soweit, aber ich würde trotzdem gerne nochmal auf hdi's Vorschlag zurückkommen. Ich hab jetzt verstanden, dass die Kommunikation nur über eine 3. Klasse funktionieren kann und hab mir mal versucht ein allgemeineres Beispiel zu bauen, in welchem die Klasse B versucht einen String info aus der Klasse A auszulesen ohne dass A oder B sich gegenseitig kennen.
[highlight=Java]
class A {
private String info = "foo";
public String getInfo() {
return info;
}
}

class B {
private Transporter transporter = new Transporter();
public String getInfo() {
return transporter.getInfo();
}
}
class Transporter {
private String transporterInfo;
public void setInfo(String infoFromA) {
transporterInfo = infoFromA;
}
public String getInfo() {
return transporterInfo;
}
}
[/highlight]

Wie bekomme ich jetzt die info in den Transporter? Das kann ja eigentlich nur die Klasse A machen. Aber wenn ich da einen Transporter anlege, hab ich ja 2 Transporter (einen in A und einen in B, der keine Info hat).

 

[benders]

Das ist doch das bekannte Observable-Observer Problem.

PanelA extends Observable und schickt das TransporterObjekt an PanelB.

PanelB implements Observer.

Im ScoutPanel registrierts Du
PanleB als Observer von PanelA

PanelB.addObserver(PanelB)

 

[dable]

Ja, da habe ich auch schon dran gedacht. Das Problem ist eben, dass im ursprünglichen Beispiel PanelA schon von JPanel erbt, also nicht noch zusätzlich von Observable erben kann.

 

[Marco13]

Wenn du genau weisst dass du sie nicht flexibel brauchst, weil sich eh nix dran ändert, ...

... wirst du mit hoher Wahrscheinlichkeit früher oder später eines besseren belehrt. Zumindest habe ich die Erfahrung gemacht, dass man sehr oft, wenn man "weiß" dass sich irgendwas garantiert NIE ändern KANN, und man es dann deswegen NICHT als Interface implementiert, man sich später darüber ärgert. Und das mit solcher Beständigkeit und in bezug auf so viele scheinbare Kleinigkeiten, dass ich mich immer mehr bemühe, an dem (manchmal, auf den ersten Blick vielleicht theoretisch und praxisfern wirkenden) Vorgehen auszurichten, erstmal ALLES (also wirklich jeden Firlefanz-Mist) als Interface zu beschreiben - egal, was ich zu diesem Zeitpunkt "weiß" und was nicht...

Observer/Observable ist nur ein Muster, nach dem man sich richten kann - das heißt nicht, dass irgendjemand von der (in Java vorgegebenen) Klasse "Observable" erben muss. Abgesehen davon sollte im Allgemeinen(!) nicht das GUI (also das JPanel) Observable sein, sondern das Datenmodell. Und das... ja ... ist ja erstmal nur ein Interface

 

[benders]

Kurze Idee:

Transporter observable machen.

Im PanelA ein TransporterObject erzeugen.
und Getter Methode auf das TransporterObject schreiben;

Im ScoutPanel
PanelA.getTransporter.addObserver(PanelB);

Geht das ?

 

[Marco13]

Je nachdem, welche Teile von dem ganzen Konstrukt private und welche öffentlich sind, könnte man auch in Erwägung ziehen, dass das andere Panel schlicht und einfach auch das TableModel kennt und ein TableModelListener ist - aber sowas muss man sich natürlich (vorher!) genau überlegen...

 

[Gast2]

Also du kannst die beiden Panels auch beim Model als Listener registrieren und das Model wirft dann events wenn es sich ändert und in beiden Panel hast du eine Referenz des Models...