Verständnisfrage zu Observer/Observable

[Katfani]

Hallo,

ich hab eine Verständnisfrage zu Observer/Observable und dem Thema Vererbung.

Ich habe einige Dialoge die ich beobachten möchte.
Normal hätte ich jetzt

public class ConfigStartPage extends Observable
{
}

machen wollen. Aber meine Dialoge erben schon die Eigenschaften von CreateDialog

public class ConfigStartPage extends CreateDialog
{
}

CreateDialog besitzt die immer wiederkehrenden Grundeigenschaften meiner Oberfläche.

Da ich ja leider nicht wirklich mit der Mehrfachvererbung arbeiten kann, dachte ich mir könnte ich doch meine CreateDialog Klasse von Observable ableiten lassen.

public abstract class CreateDialog extends Observable
{
}

Doch dies hab ich mir wohl zu einfach gedacht da ich ja in meinen Dialogklassen nicht einfach super.setChanged() etc. machen kann.

Wie kann ich das jetzt lösen Was wäre da am sinnvollsten..

Und wenn ich es mir recht überlege kann ich auch nicht die Dialoge einzeln beobachten wenn ich CreateDialog von Observable erben lasse..

Kann ich irgendwie eine Mehrfachvererbung simulieren?

Vielen Dank schon im vorraus fürTipps und Anregungen!


EDIT:
Ich könnte natürlich auch von meinen Dialogen aus, eine Funktion in CreateDialog aufrufen die einem Beobachter für alle bescheid gibt, das sich etwas geändert hat und dann irgendwie die Aufgaben verteilen, je nachdem aus welchem Dialog der Aufruf kam. Irgendwie so *malnachenkenmuss*

 

[zerix]

Hallo,

irgendwie verstehe ich im moment dein Problem nicht.
Warum sollte es mit Vererbung nicht funktionieren bzw was funktioniert nicht?

MFG

zEriX

 

[Katfani]

Hallo,

also momentan habe ich zu jedem Dialog ein Gegenstück in der Logik was seine Angelegenheit regeln soll.

Angedacht war das ich den Dialog mit dem Observable ausstatte und das Gegenstück mit dem Observer. So wäre es ja recht einfach..

Das Problem aber ist das meine Dialoge schon von einer Klasse namens CreateDialog erben, da ich eben eine immer wiederkehrende Oberfläche habe.

CreateDialog hat sozusagen viele kleine Dialogkinder die ich ursprünglich einzeln beobachten wollte.. Da es aber bei Java nicht geht das ich von zwei Klassen ableiten kann muss ich mir jetzt etwas anderes überlegen.

Mittlerweile habe ich zum testen einen Beobachter gebaut und CreateDialog zum Beobachtbaren gemacht. Wenn nun auf dem Dialog ein Button gedrückt wird, rufe ich eine Funktion in CreateDialog auf die dem Beobachter mit setChanged()usw. bescheid gibt das etwas passiert ist. Der Beobachter muss dann die Aufgaben an die Gegenstücke verteilen.. Ist auch eine unschöne Lösung..
Aber ich weiß nicht ganz wie ich den Dialog mit seinem Gegenstück in der Logik direkt überwachen kann, ohne CreateDialog und einem Beobachter der die Aufgaben verteilt.

Verstehst du was ich meine

 

[wasted time]

Hi,

ich habe da auch mal eine Frage, warum willst du deine Dialoge beobachten? Im Regelfall beobachtet die GUI ein Modell (die Business Logik, Objekte, die die Problemdomäne abdecken) und aktualisiert sich bzw. macht irgendwas nach Modelländerungen. Dazu benutzt es das Observer-Design-Pattern um über diese Änderungen informiert zu werden.

So wie ich dich verstehe, benutzt du das Observer-Konzept, um zu entscheiden, was beim Klicken eines Buttons getan werden soll.(?)
Warum nicht gleich im Dialog, d.h. im entsprechenden EventHandler des Buttons, die entsprechenden Schritte erledigen?

Zu deinem Problem, spendiere deinem CreateDialog einfach die entsprechden Observable Methoden, d.h. implementiere sie selbst. Kannst dir ja den Quellcode von der originalen Observable Implementierung angucken, müsste irgendwo im JDK-Verzeichnis liegen. Die ist ziemlich einfach gestrickt.


mfg
wasted time

 

[Proko]

was ich noch nicht verstehe:

warum darf die klasse nicht beides erweitern, also so ausschauen? (wäre ja in meinen augen der richtige OOP ansatz)

public class ConfigStartPage extends Observable, CreateDialog
{
}

 

[zerix]

was ich noch nicht verstehe:

warum darf die klasse nicht beides erweitern, also so ausschauen? (wäre ja in meinen augen der richtige OOP ansatz)

Das wäre Mehrfach-Vererbung und das geht in Java nicht. Mit Interfaces kann man was ähnliches erreichen.



@Katfani
Da deine Oberklasse von CreateDialog erbt, erben die "Kinder" diese Eigenschaften auch mit. Du musst ein Methode auch nur mit super aufrufen, wenn du sie in der KindKlasse überschrieben hast. Sonst kannst du sie normal aufrufen. Also im Moment verstehe ich nicht ganz was da nicht funktioniert.

MFG

zEriX

.

 

[limago]

Hi,

ich habe da auch mal eine Frage, warum willst du deine Dialoge beobachten? Im Regelfall beobachtet die GUI ein Modell (die Business Logik, Objekte, die die Problemdomäne abdecken) und aktualisiert sich bzw. macht irgendwas nach Modelländerungen. Dazu benutzt es das Observer-Design-Pattern um über diese Änderungen informiert zu werden.

So wie ich dich verstehe, benutzt du das Observer-Konzept, um zu entscheiden, was beim Klicken eines Buttons getan werden soll.(?)
Warum nicht gleich im Dialog, d.h. im entsprechenden EventHandler des Buttons, die entsprechenden Schritte erledigen?

Zu deinem Problem, spendiere deinem CreateDialog einfach die entsprechden Observable Methoden, d.h. implementiere sie selbst. Kannst dir ja den Quellcode von der originalen Observable Implementierung angucken, müsste irgendwo im JDK-Verzeichnis liegen. Die ist ziemlich einfach gestrickt.


mfg
wasted time

Ich teile die Einschätzung, dass Dein Ansatz falsch ist. Dennoch Lösung eins:

package de.tutorials;

import java.util.Observable;
import java.util.Observer;

public class DialogSimulation extends Object{
	
	private MyObservable observable = new MyObservable();
	
	DialogSimulation(){
		
		//... Dialog inititialisieren
	}

	public void addObserver(Observer o) {
		observable.addObserver(o);
	}

	public void deleteObserver(Observer o) {
		observable.deleteObserver(o);
	}
	
	private void fireEvent(/* Was auch immer */) {
		observable.fireEvent(/* Was auch immer */);
	}

	class  MyObservable extends Observable {
		public void fireEvent(/* Was auch immer */) {
			setChanged();
			notifyObservers(/* Was auch immer */);
		}
	};
	
}

Lösung 2 selber stricken...

package de.tutorials;

import java.util.ArrayList;
import java.util.List;


public class DialogSimulation extends Object{
	
	private List<MyListenerInterface> listeners = new ArrayList<MyListenerInterface>() ;

	public void add(MyListenerInterface element) {
		listeners.add( element);
	}

	public boolean remove(Object o) {
		return listeners.remove(o);
	}
	
	public void fireEvent(Object event) {
		for(MyListenerInterface listener: listeners)
			listener.tueWas(event);
	}
	
}

package de.tutorials;

public interface MyListenerInterface {
	
	public void tueWas(Object o);

}

 

[limago]

@zerix

gut delegiert ist manchmal besser als vererbt ;-)

 

[zerix]

@ limago

schon klar. Hab nur an das Problem gedacht und mich gewundert dass es nicht funktionieren soll.

MFG