MVC - Vererbung

[schnepfo]

hallo,

ich hab in einem Projekt das MVC Design Pattern angewendet, jedoch stoße ich mittlerweile auf meine grenzen.

Kurze Beschreibung:

Ich habe eine MainApplication (View) die das Hauptfenster darstellt.
Ich habe einen Controller der die handlungen steuert und ein Model.

Weiters sind jedoch auf der MainApplication lauter Buttons, und bei jedem Button soll ein neues Formular angezeigt werden, wobei sich die Formulare in ihrem Aussehen, den daten und den Funktionen unterscheiden.

Nun zu meiner Frage:

Wie kann ich hier Vererbung gut nutzen?

Denn ich habe jetzt die Superklassen View,Controller und Model.

Beim Model funktioniert das alles sehr gut, da nutze ich nur die zentrale Klasse.

Jedoch beim View muss ich immer eine Subklasse machen die von View erbt. Soweit so gut. Nur muss ich dem Controller auch immer die View übergeben.

Ich dachte zuerst daran, dass ich einfach die Superklasse View übergebe und diesem Objekt dann das Objekt der Subklasse zuweise. Jedoch geht mir dabei die ganze Funktionalität der Subklasse verloren, da ich ja nur die Methoden nutzen kann die ich auch in der Superklasse habe.

Deshalb musste ich auch für jeden einzelnen Controller eine eigene Klasse machen,die von Controller erbt.

Das was die Subklassen erben, ist jedoch nicht sehr viel, da nur 1-2 Methoden bei allen gleich sind.

Habe ich einen Denkfehler oder ist das MVC Konzept bei solchen Dingen nur so einzusetzen?

lg

 

[Gonzo17]

Ich dachte zuerst daran, dass ich einfach die Superklasse View übergebe und diesem Objekt dann das Objekt der Subklasse zuweise. Jedoch geht mir dabei die ganze Funktionalität der Subklasse verloren, da ich ja nur die Methoden nutzen kann die ich auch in der Superklasse habe.

Also nach meinem Verständnis ist hier das Problem. Wieso möchtest du im Controller auf Methoden vom View zugreifen? Was genau willst du machen? Ich würde das nämlich eher andersherum sehen. Der View kennt seinen Controller und wenn ein Benutzer zB auf einen Button klickt und Funktion x aufgerufen werden soll, dann fragt der View beim Controller an, der führt die Funktion x aus und liefert das Ergebnis zurück bzw schreibt es ins Model. Wenn der View dann als Observer auf Änderungen beim Model wartet, dann kriegt er auch automatisch mit, wenn sich etwas ändert.

 

[schnepfo]

Nach meinem Verständnis hat die View Kenntnis über das Model und den Controller .

Auch ZB in Wikipedia so definiert: Die Präsentationsschicht ist für die Darstellung der benötigten Daten aus dem Modell und die Entgegennahme von Benutzerinteraktionen zuständig. Sie kennt sowohl ihre Steuerung als auch das Modell, dessen Daten sie präsentiert, ist aber nicht für die Weiterverarbeitung der vom Benutzer übergebenen Daten zuständig.

Also bei mir ist es so das der Controller den Programablauf steuert, dh.: Wird ein Button gedrückt, wird dies durch den Controller erfasst, der teilt der View mit was angezeigt werden soll, und dem Model was gespeichert werden soll, und übernimmt selbt die verarbeitung der Daten.

So hab ichs zumindest gelernt und auch verstanden...

lg

 

[Gonzo17]

Nochmal zurück zum ursprünglichen Problem. Da du ja schon auf Wikipedia verweist, hier auch noch ein Ausschnitt.

Deshalb musste ich auch für jeden einzelnen Controller eine eigene Klasse machen,die von Controller erbt.

Die Steuerung verwaltet eine oder mehrere Präsentationen, nimmt von ihnen Benutzeraktionen entgegen, wertet diese aus und agiert entsprechend. Zu jeder Präsentation existiert eine Steuerung. Es ist die Aufgabe der Steuerung, Daten zu manipulieren. Die Steuerung entscheidet aufgrund der Benutzeraktion in der Präsentation, welche Daten im Modell geändert werden müssen. Sie enthält weiterhin Mechanismen, um die Benutzerinteraktionen der Präsentation einzuschränken. Die Steuerung kann in manchen Implementierungen ebenfalls zu einem „Beobachter“ des Modells werden, um bei Änderungen der Daten den View direkt zu manipulieren.

Generell muss man das aber auch von einer anderen Seite sehen. Jedes (Design-)Pattern ist lediglich eine Art Denkanstoß, um seinem Code bestimmte Strukturen zu geben. Wie man es letztlich umsetzt kann man selbst entscheiden. Gerade MVC lässt ja viele Dinge offen, die man so oder eben so umsetzen kann. Es gibt bestimmt auch Fälle, die nur mit einem Controller arbeiten. Die Frage ist ja immer, was man machen möchte.

Wichtig finde ich nur, dass man im Zusammenhang mit MVC eben auch mal das Observer-Pattern versucht, das kann nämlich durchaus helfen.

 

[Michael...]

Auch ZB in Wikipedia so definiert: Die Präsentationsschicht ist für die Darstellung der benötigten Daten aus dem Modell und die Entgegennahme von Benutzerinteraktionen zuständig. Sie kennt sowohl ihre Steuerung als auch das Modell, dessen Daten sie präsentiert, ist aber nicht für die Weiterverarbeitung der vom Benutzer übergebenen Daten zuständig.

Die View kennt den Controller nur indirekt z.b. über ein Interface
Controller "kennt" View und Model (konkret)
View "kennt" Model (konkret - kann aber auch abstrakt sein)
Model weiß dass es Views gibt (abstrakt)
View weiß, dass es einen Controller gibt (abstrakt)

Also bei mir ist es so das der Controller den Programablauf steuert, dh.: Wird ein Button gedrückt, wird dies durch den Controller erfasst, der teilt der View mit was angezeigt werden soll, und dem Model was gespeichert werden soll, und übernimmt selbt die verarbeitung der Daten.

Meiner Meinung sollte es für den Controller irrelevant sein, ob ein Button gedrückt oder eine JCheckBox selektiert oder... wurde.
Der ActionListener für den Button kann in der View implementiert sein, interpretiert das ActionEvent und ruft die passende (Interface)Methode des Controllers auf.

Deine Überlegung einer SuperView und SubViews die von Ihr erben, kommt mir etwas komisch vor und macht eigentlich keinen Sinn. Man könnte sich ggf. überlegen ein Interface View zu definieren, um die Kopplung noch loser zu gestalten. Man sollte es sich aber nicht unnötig schwer machen.