# Kommunikation zwischen Klassen



## monade (27. Mrz 2008)

Hi,
mal eine prinzipielle Frage:
Angenommen ich hab 3 Klassen A,B,C und mein Code sieht etwas so aus:

```
public class A extends JPanel{
	
	private B classB = new B();
	private C classC = new C(); // B, C extends JComponent/JWhatever..

	public A(){
		this.add(classB);
		this.add(classC)
	}
	
}
```
Jetzt will ich, dass die Klassen/Komponenten classB und classC kommunizieren können, also dass sich C updated, wenn sich in B was ändert, und umgekehrt. In meinen JAVA-Anfängen hab ich das jetzt so gemacht, dass ich für B und C ein gemeinsames Model definiert und zusätzlich B und C als Listener für das Model registriert habe. Hat soweit auch funktioniert, aber irgendwie stößt das langsam an Grenzen. In meinem jetztigen Projekt hab ich zig Klassen, die alle untereinander kommunizieren müssen. Ein gemeinsames Model für alle Klassen zu definieren ist irgendwie idiotisch, weil Klasse B mit Klasse C andere Informationen austauschen muss, wie Klasse C mit Klasse D. Außerdem widerspricht es meine ich dem Grundgedanken des Models.
Ich bin sicher, dass es für sowas Grundlegendes schon Lösungen geben muss, könnt ihr mir da auf die Sprünge helfen?

Vielen Dank,
monade


----------



## sliwalker (27. Mrz 2008)

Hi,

man hört das Dir klar ist, dass man das nicht in einem Satz erklären kann. Aber damit Du die Richtung weist, folgendes:

1. Du kannst Interfaces verwenden, damit Du sichergehen kannst, dass eine bestimmte Methode in einer fremden Klasse vorhanden ist. So könntest Du in A etwas ändern und weißt, dass Du in B die Methode updateB() aufrufen kannst, der Du dann das geänderte A mitgeben kannst.
(Ist viel Schreibarbeit, aber eine durchaus gute Lösung...gerade bei vielen Klassen.)

2. Du kannst ein Entwurfsmuster umsetzen...und zwar das ObserverPattern(gibts auch ein FAQ-Eintrag) in diesem Forum.
Dort registrierst Du Klassen bei einem Observer, die immer nach einer Änderung an einem Model benachrichtigt werden...sprich es wird bei einer Änderung eine bestimme Methode aufgerufen, die das geänderte Objekt(Model) mitbekommt.


Beides Ansätze, die bei Dir klappen müssten.

greetz
SLi


----------



## SlaterB (27. Mrz 2008)

also ein gemeinsames Model ist ja schon bisschen was anderes als sich 'nur' in bestimmten Situationen gegenseitig zu informieren,

wenn du die gemeinsmen Models brauchst, dann musst du sie notfalls in einer hohen Zahl einfügen für jedes Paar von Klassen,
diese enthalten dann ja auch echte, insbesondere unterschiedliche Informationen, 
die kann man nicht generalisieren

wenns nur um Informierung geht, dann reichen doch allseits beliebte Listener/ Observer usw.,
zunächst mal muss jede Klasse ein Observer sein, wenn man es ganz allgemein baut, kann als Ereignis fast nur ein Objekt gegeben werden,
bestenfalls ein gemeinsames Interface aller fraglichen Klassen,

ob B nun von C oder D informiert wurde kann man dabei nicht erkennen, müsste erst manuell unterschieden werden,

alles höher typisierte erfordert wieder mehr unterschiedliche Listener

auf jeden Fall kann man bei sowas einfache Hilsoperationen wie
registriereGegenseitig(objectB, objectC); aufrufen, oder
registriereAlleUntereinander(objectB, objectC, objectD);
---------

was mir spontan noch einfällt: anonyme kleine Listener, die die schwachte Typisierung etwas aufheben,


```
registriereGegenseitig(
  objectB, 
  new ListenerXY() {
    public void event(Object x) {
      objectB.eventTypC((C) x);
    }
  },
  objectC,
  new ListenerXY() {
    public void event(Object x) {
      objectC.eventTypB((B) x);
    }
  },
);
```
hier wird bei objectC der erste Listener registriert, der dann bei objectB die Operation eventTypC() aufruft,
bei objectB genau andersrum


----------



## monade (27. Mrz 2008)

SlaterB hat gesagt.:
			
		

> wenn du die gemeinsmen Models brauchst...





			
				SlaterB hat gesagt.:
			
		

> wenns nur um Informierung geht...



Im Grunde brauche ich beides. Für das gegenseitige Informieren über Änderungen ist das ObserverPattern-Konzept ziemlich interessant, danke für den Tip! 
Es ist aber tatsächlich so, dass die meisten Klassen auch gemeinsame Models benötigen. Im Moment hab ich ein riesengroßes Model, und viele Klassen nutzen (sich überschneidende) Teile dieses Models. Angenommen in meinem Model sind die Variablen v,w,x,y,z definiert, dann benötigt etwa Klasse B das Wissen um v,w,x,y und Klasse C x,y,z, usw.
Wie auch immer ich es löse ists ungeschickt. Definiere ich für B und C ein eigenes Model, hab ich die doppelte Information x,y,z (und noch dazu das Problem der "Synchronisation", wenn sich x,y,z ändern), bleibe ich beim gemeinsamen großen Model, so ist ist etwa für C die Information v,w eigentlich redundant. Definiere ich wiederum für B ein Model mit v,w, für C ein Model mit z und ein gemeinsames Model x,y, hab ich spätestens bei der Klasse D, die v und z benötigt, ein Problem. Dann brauch ich nämlich gemeinsame Models D-B, D-C, usw. usw. und im Endeffekt lande ich hier:


			
				SlaterB hat gesagt.:
			
		

> wenn du die gemeinsmen Models brauchst, dann musst du sie notfalls in einer hohen Zahl einfügen für jedes Paar von Klassen


was auch sehr unschön ist. Gibt es da keinen Ausweg?

Und noch eine Frage: im MVC-Konzept gibt es für einen View in den Tutorials immer die Getter und Setter setModel()/getModel(). Was aber ist dann die "Code-Konvention", wenn ich wie in meinem Fall mehrere Models für meinen View brauche. Definiere ich dann im View einfach setModel1()/setModel2()... ? Oder gibts ne andere Konvention (zB die Models zusammenfassen zu einem SuperModel)?


----------

