MCV, Document/View

[axeljaeger]

Man hört ja viel vom MCV Designpattern. Gelesen hab ich da auch schon viel, mit Kästchen, welche Klasse welche Rolle spielt. Klar ist mir, dass man die Sicht von den Daten trennt, so dass man mehrere Sichten pro Datenmodel haben kann. Toll. Jetzt will ich mal etwas konkreter werden: Eine Klasse Data hat intern eine Liste mit Observern, in denen etwa eine Methode Update aufgerufen wird. Daraufhin zeichnet sich jeder View neu.

War das alles? Wird darum so ein Bohai gemacht? Wenn das Document/View ist, was ist dann Controller im MCV-Modell? Irgendwie sind alle Anleitungen zu Designpatterns sehr abstrakt. Ich hab schon überlegt, dieses tolle Designpatternbuch zu kaufen, aber nach einem Probekapitel ist mir beinahre schlecht geworden, da dass dermaßen abstrakt ist, dass ich damit nichts anfangen kann.

[anda_skoa]

Original geschrieben von axeljaeger
War das alles? Wird darum so ein Bohai gemacht?

Designpatterns sind nur Lösungsmuster für häufige Probleme, sie müssen dazu nicht komplex sein.
Im Grunde genommen sind die meisten Pattern sehr einfach, man hat sie meisten schon eingesetzt, als man noch nicht wusste, dass es diese Pattern gibt.
Die Bücher beschreiben aber neben dem Pattern auch die Auswirkungen und Vorraussetzungen, etwas, das man selbst vielleicht nicht vollständig wissen könnte.

Es geht auch darum, zwischen Entwicklern ein gemeinsames Vokabular zur Verfügung zu haben.



Wenn das Document/View ist, was ist dann Controller im MCV-Modell?

Es gibt dann einfach noch einen Dritten, der die Operationen auf dem Document macht.
Beispiel wäre zB eine GUI Anwendung mit Hauptfenster+Menü+Toolbars, mit eingebettem View und einem Document.
Da ist das Hauptfenster mit seinen Implementationen der Steuerung der Controller, es veranlasst zB das Speichern.



Irgendwie sind alle Anleitungen zu Designpatterns sehr abstrakt. Ich hab schon überlegt, dieses tolle Designpatternbuch zu kaufen, aber nach einem Probekapitel ist mir beinahre schlecht geworden, da dass dermaßen abstrakt ist, dass ich damit nichts anfangen kann.
Die Benutzung von Design Patterns muss man üben, das ist wie der Unterschied zwischen "drauf los coden" und "zuerst überlegen und dann coden".

Falls du dich auf das Buch "Entwurfsmuster" von Gamma u.a. beziehst, das ist sehr gut, behandelt es doch alle Standardmuster, aufgeteilt in drei Kategorieren (Erzeugung, Verhalten, Struktur)

Mächtig werden Muster oft nur in Verbindung mit anderen, zB Factory+Bridge, um Objekte nach Parametern zu erzeugen und keine Implementations Details nach außen durchzulassen.

Aber da es hier um Design geht, ist das nicht so einfach zu erlernen, das ist nicht so wie ein Tutorial für ein neues Widgetset durchzumachen, das ist vielmehr eine neue Vorgehensweise zu probieren.

Ciao,
_

[axeljaeger]

Original geschrieben von anda_skoa
Designpatterns sind nur Lösungsmuster für häufige Probleme, sie müssen dazu nicht komplex sein.
Im Grunde genommen sind die meisten Pattern sehr einfach, man hat sie meisten schon eingesetzt, als man noch nicht wusste, dass es diese Pattern gibt.


Stimmt, man kommt sogar gelegentlich selber drauf und ist dann umso überraschter, dass es schon dokumentiert ist, war bei mir mit dem Observer so,


Original geschrieben von anda_skoa

Es gibt dann einfach noch einen Dritten, der die Operationen auf dem Document macht.
Beispiel wäre zB eine GUI Anwendung mit Hauptfenster+Menü+Toolbars, mit eingebettem View und einem Document.
Da ist das Hauptfenster mit seinen Implementationen der Steuerung der Controller, es veranlasst zB das Speichern.


Und das hat mich ein bißchen verwirrt: Normalerweise kann man ja in jedem View die Daten verändern. Ist dass dann Controller und View in einem? Oder ist die Klasse, in der die Datenmodelle stehen, der Controller?


Original geschrieben von anda_skoa

Die Benutzung von Design Patterns muss man üben, das ist wie der Unterschied zwischen "drauf los coden" und "zuerst überlegen und dann coden".


Es ist in der Praxis für mich noch schwierig, so zu planen, dass alles am Anfang mit drinn ist und nicht später mit Flickschustermethoden noch Features dazu müssen. Ist wohl Erfahrungssache.


Original geschrieben von anda_skoa

Falls du dich auf das Buch "Entwurfsmuster" von Gamma u.a. beziehst, das ist sehr gut, behandelt es doch alle Standardmuster, aufgeteilt in drei Kategorieren (Erzeugung, Verhalten, Struktur)


Ich hab mir da mal 100 Seiten oder wie viele man zum Probelesen runterladen kann, besorgt und ich fand es nicht so dolle.


Original geschrieben von anda_skoa

Mächtig werden Muster oft nur in Verbindung mit anderen, zB Factory+Bridge, um Objekte nach Parametern zu erzeugen und keine Implementations Details nach außen durchzulassen.


Ja, wobei der Vorteil dieser Methoden, finde ich, da nicht richtig rauskommt. Mit properties und factorys auf Stringbasis könnte man sehr viele, schön anschauliche Beispiele machen.

[anda_skoa]

Original geschrieben von axeljaeger
Und das hat mich ein bißchen verwirrt: Normalerweise kann man ja in jedem View die Daten verändern. Ist dass dann Controller und View in einem? Oder ist die Klasse, in der die Datenmodelle stehen, der Controller?

Das MVC Modell ist ja eine Erweiterung des Document/View Modells, eben wenn man zB Aktionen hat, die unabhängig vom View am Document ausgeführt werden, eben zB Speichern, Laden, etc.
Oder in einer MDI Anwendung, wo man nur einen Controller braucht, aber viele Model/View Kombinationen damit verwalten kann.


Original geschrieben von axeljaeger

Es ist in der Praxis für mich noch schwierig, so zu planen, dass alles am Anfang mit drinn ist und nicht später mit Flickschustermethoden noch Features dazu müssen. Ist wohl Erfahrungssache.

Stimmt, ist es sicher. Hab ja schon geschrieben, dass das nur durch Übung kommt.
Man muss praktisch ein Pattern schon mal verwendet haben, um es nächstes Mal planen zu können.
Patterns können aber oft helfen, im Nachhinein Ordnung zu schaffen, wenn man Refactoring macht.


Original geschrieben von axeljaeger

Ich hab mir da mal 100 Seiten oder wie viele man zum Probelesen runterladen kann, besorgt und ich fand es nicht so dolle.

Ich benutze es hauptsächlich um mir Überblick über die Möglichkeiten zu schaffen, bzw. bei ähnlichen Pattern das passende auszusuchen.
Aber wie gesagt ist das Verwenden von Patterns bzw das Denken in Patterns ein Übungsprozess.



Original geschrieben von axeljaeger

Ja, wobei der Vorteil dieser Methoden, finde ich, da nicht richtig rauskommt. Mit properties und factorys auf Stringbasis könnte man sehr viele, schön anschauliche Beispiele machen.
Je konkreter man die Beispiele macht, desto eher läuft man Gefahr, dass Teile des Beispiels als Teile des Patterns missverstanden werden.

"Gutes" Beispiel ist da eben Factory.
Wenn man immer nur Code sieht, wo eine Klasse über den Klassennamen erzeugt wird, übersieht man leicht, dass die übergebenen Daten nur eine Art Kontext darstellen, mit dem die Factorymethode entscheiden kann, was sie produzieren soll.

Ciao,
_