MVC und EventListener

[multiholle]

Wenn ich ein Programm nach dem MVC-Konzept entwerfe dann implementiere ich die GUI in der View. Wo implementiere ich dann die Eventlistener der einzelenen Komponenten? Bis jetzt habe ich das immer gleich beim hinzufügen getan:
[highlight="java"]volumeSlider.addChangeListener(new ChangeListener() {
@Override
public void stateChanged(ChangeEvent e) {
JSlider src = (JSlider) e.getSource();
SoundEngine.setVolume((float) src.getValue() / 100, media);
}
});[/highlight]
Eigentlich gehören die doch in den Controller, oder? Nur muss dann der Controller sämtliche Eventlistener implementieren. Das wird doch recht unübersichtlich...

 

[SlaterB]

da gibts diverse Umsetzungsstufen, statt eines Controllers könnten es auch mehrere Klassen für unterschiedliche Bereiche sein,

der komplizierte Listener + die Abfrage der Quell-Swing-Komponente ist aus einer separaten Klasse heraus auch recht aufwendig,
wenn schon, dann könnte man

public void stateChanged(ChangeEvent e) {
JSlider src = (JSlider) e.getSource();
controller.handleChangeAtSliderXY(src.getValue());
}
programmieren und der Controller muss nur den den Wert korrekt übersetzt an die SoundEngine weitergeben,
bei einem Einzeiler kann man andererseits manchmal auch drauf verzichten

Grundregel könnte sein:
ein Pattern bzw. sonstige Paradigmen (MVC gilt nicht als Pattern) nur dann einsetzen, wenn man weiß warum und es aktuell auch nützlich ist

 

[Ebenius]

MVC gilt nicht als Pattern

MVC ist kein Entwurfsmuster (Design Pattern), aber ein Architekturmuster (Architectural Pattern).

Ebenius

 

[multiholle]

ein Pattern bzw. sonstige Paradigmen (MVC gilt nicht als Pattern) nur dann einsetzen, wenn man weiß warum und es aktuell auch nützlich ist

Das ist mir schon bewusst, bei dem Aufwand den das Konzept nach sich zieht

public void stateChanged(ChangeEvent e) {
JSlider src = (JSlider) e.getSource();
controller.handleChangeAtSliderXY(src.getValue());
}

Das würde ja bedeuten, dass in deinem Fall die View den Controller kennt. Eigentlich kennt die View doch nur das Model und der Kontroller kenn View und Model. Dann müsste ich ja beim erzeugen einer neuen View den Controller mit übergeben.

 

[SlaterB]

wenn du darin ein Problem siehst, na dann eben nicht
dann musst du wirklich streng alle Listener im Controller definieren oder ganz darauf verzichten

die Verzahnung wäre ansonsten halbwegs beherrschbar:
sie betrifft zum einen sowieso nicht direkte View-Klassen wie JTable, JSlider usw,
sondern nur den Code, der die GUI zusammenbaut, normalerweise macht man das (sicher nicht ganz korrekt) in einer Unterklasse von JFrame und zählt das zum View dazu,
je nach Interpretation könnte man das aber auch als eine Teilaufgabe des Controllers sehen

desweiteren dürfte der Controller-Einbau immer nach diesem festen Schema erfolgen,
ließe sich später also im Notfall hoffentlich auch immer wieder auf gleiche Weise entfernen,

schlimmstenfalls hätte man also ab diesen Zeitpunkt dann die langweiligen Listener im Controller,
wenn es unumgänglich wird (weil man den GUI-Erstellungscode irgendwie mehrfach verwenden möchte oder so),

ob das dann wirklich noch wartbar/ umbaubar ist, ist natürlich nur optimistischer Glaube


edit:
ohne den Code zur Erstellung der GUI hätte man an View gar nix zu programmieren, auch nicht so spannend

vielleicht dann den Controller wenigstens zweistufig: eine Klasse nur für richtige Aktionen, die man vielleicht auch von mehreren Stellen aus aufrufen kann,
und eine Klasse die nur die fast ebenso langen Standard-Listener enthält, von den GUI-Klassen die Werte abfragt und gebündelt Methoden des 'richtigen' Controllers aufruft