Normal
Die saubere Trennung von Eingabe, Verarbeitung und Ausgabe (EVA) würd' ich sagen. Es ist auch keine Schande, die Listener in die View zu packen, nur darf man nie vergessen, den Controller über auftredende Events zu informieren bzw. die Events an diesen weiter zu leiten. Das würde aber bedeuten, dass die View Kenntnis vom Controller haben muss. Letztendlich ist's doch nur 'ne Designfrage, wer wen kennen soll. Wenn man die Listener in der View hat kommt man recht schnell in die Verlegenheit Parameter der View zu ändern, ohne Model und oder Controller darüber zu informieren. Am Ende forscht man dann an den falschen Stellen nach Dateninkonsistenz.@HazelNut: wieso denn gleich Vererbung? Schreib' 'ne Methode in die Views, wo ein Controller ControlListener registrieren kann. Da kannst du dann im Zweifelsfall sogar alle verwendeten Listener (sind ja durchweg Interfaces) als gebündelte Klasse übergeben. Naja... das dann doch eher unsauber, also vergiss das wieder (bis auf die Sache mit den Registrier-Methoden ).Ausserdem haben "Views" (z.B. Swing-Komponenten) ja schon entsprechende Methoden: "dispose()", "setVisible()", "setEnabled()"... steht doch in deinem Link alles wunderbar beschrieben... (der Controller hat keine Listener, er ist ein Listener... auch nicht schlecht. Naja... XD)
Die saubere Trennung von Eingabe, Verarbeitung und Ausgabe (EVA) würd' ich sagen. Es ist auch keine Schande, die Listener in die View zu packen, nur darf man nie vergessen, den Controller über auftredende Events zu informieren bzw. die Events an diesen weiter zu leiten. Das würde aber bedeuten, dass die View Kenntnis vom Controller haben muss. Letztendlich ist's doch nur 'ne Designfrage, wer wen kennen soll. Wenn man die Listener in der View hat kommt man recht schnell in die Verlegenheit Parameter der View zu ändern, ohne Model und oder Controller darüber zu informieren. Am Ende forscht man dann an den falschen Stellen nach Dateninkonsistenz.
@HazelNut: wieso denn gleich Vererbung? Schreib' 'ne Methode in die Views, wo ein Controller ControlListener registrieren kann. Da kannst du dann im Zweifelsfall sogar alle verwendeten Listener (sind ja durchweg Interfaces) als gebündelte Klasse übergeben. Naja... das dann doch eher unsauber, also vergiss das wieder (bis auf die Sache mit den Registrier-Methoden ).
Ausserdem haben "Views" (z.B. Swing-Komponenten) ja schon entsprechende Methoden: "dispose()", "setVisible()", "setEnabled()"... steht doch in deinem Link alles wunderbar beschrieben... (der Controller hat keine Listener, er ist ein Listener... auch nicht schlecht. Naja... XD)
