Seite 1 von 1

GRASP Use Case Controller

Verfasst: 23. Dez 2011 11:31
von SupeRalF
Ich habe eine Frage zum UseCase Controller:
Beim Use Case Controller wird ja der gesamte Use Case von nur einer einzigen Klasse verarbeitet. Handelt es sich auch um einen Use Case Controller, wenn Sowohl die Deklaration eines Buttons, also auch dessen ActionListener und die Behandlung dessen alles in einer Klasse geschieht? Oder darf auch bei einem Use Case Controller die eine Klasse nur die Funktionen einer anderen Klasse aufrufen, welche für den Use Case verantwortlich ist?

Re: GRASP Use Case Controller

Verfasst: 27. Dez 2011 13:16
von eichberg
Ich bin mir nicht 100% sicher ob ich Ihre Frage richtig verstehe - falls Folgendes Ihre Frage nicht beantwortet, dann empfehle ich Ihnen den Besuch der Sprechstunde eines Tutors oder ggf. der Sprechstunde von Herrn Mitschke bzw. mir.

Wie in der Vorlesung besprochen gilt immer: Code, der der Implementierung der Geschäftslogik dient, sollte mit Code, der das UI implementiert, nicht vermischt werden. Da ein "Use Case Controller" ein Teil der Implementierung der Geschäftslogik ist, sollte also dort auf keinen Fall Code in Hinblick auf "Buttons" auftauchen. Ist dies dennoch der Fall, ist der Code schwer wieder verwendbar bzw. schlecht verständlich.

Natürlich bleibt eine Klasse, die im Wesentlichen die Logik eines Anwendungsfalls implementiert (auch wenn Sie dies in Zusammenarbeit mit vielen anderen Klassen macht) ein Use Case Controller. Dies gilt auch dann noch diese Klasse UI Code enthält. Letzteres sollten Sie aber (aus oben dargelegten Gründen) dennoch nicht machen!

Re: GRASP Use Case Controller

Verfasst: 28. Dez 2011 19:22
von SupeRalF
ich bin mir gerade selber nicht sicher, ob meine frage jetzt beantwortet ist, oder nicht. Deshalb ein konkretes Beispiel:

Angenommen ich habe den Use Case "Färbe den Hintergrund rot".
Dann erstelle ich auf der GUI einen Button, bei dessen Klick der Hintergrund rot gefärbt wird. Allen Code dafür stecke ich in die Klasse, in der auch der Button selber initialisiert wird; der Actionlistener ruft also in der gleichen Klasse, in der sich auch der Button befindet eine Funktion wie zb void faerbeHintergrundRot() auf, die nicht viel mehr macht als auf ein GUI Element setColor aufzurufen.
Dann handelt es sich NICHT um einen Controller, welcher Art auch immer, oder? Ich würde dies aktuell als Information Expert bezeichnen. Stimmt das?

Re: GRASP Use Case Controller

Verfasst: 29. Dez 2011 10:30
von eichberg
Dann erstelle ich auf der GUI einen Button, bei dessen Klick der Hintergrund rot gefärbt wird. Allen Code dafür stecke ich in die Klasse, in der auch der Button selber initialisiert wird; der Actionlistener ruft also in der gleichen Klasse, in der sich auch der Button befindet eine Funktion wie zb void faerbeHintergrundRot() auf, die nicht viel mehr macht als auf ein GUI Element setColor aufzurufen.
In diesem Beispiel beschreiben Sie eine Situation, in der Sie über den Button (welcher natürlich Teil der GUI ist) "nur" Änderungen an der GUI vornehmen wollen aber nicht am eigentlichen Datenmodel der Anwendung. D.h. ich würde bei dieser Klasse (welche den Button erzeugt, verwaltet,...) nicht von einem Use Case Controller sprechen. Aufgrund der Einfachheit des Beispiels würde ich hier aber auch nicht von der Anwendung des "Information Expert" Prinzips sprechen - im Prinzip folgt Ihr Vorschlag den Standardprinzipien: Low Coupling, High Cohesion, Low Representational Gap.

Die Anwendung der Prinzipien, bzw. das Nachdenken darüber, ist insbesondere dann von Interesse wenn Ihr Domänenmodell aus mehreren und miteinander in Verbindung stehenden Klassen besteht.

Re: GRASP Use Case Controller

Verfasst: 2. Jan 2012 14:25
von SupeRalF
eichberg hat geschrieben: In diesem Beispiel beschreiben Sie eine Situation, in der Sie über den Button (welcher natürlich Teil der GUI ist) "nur" Änderungen an der GUI vornehmen wollen aber nicht am eigentlichen Datenmodel der Anwendung.
Dies ist doch aber auch der Fall in der aktuellen Hausübung "Alle Karteikarten durchnummerieren". So wie ich das verstanden habe, sollen doch "nur" die Labels in der Liste mit einer entsprechenden Zahl versehen werden. Oder habe ich da etwas falsch verstanden?

Re: GRASP Use Case Controller

Verfasst: 2. Jan 2012 16:34
von jlerch
"Alle Karteikarten durchnummerieren".
Hier ist gemeint, dass die Karteikarten (nicht nur auf der GUI sonder auch im Datenmodell!) ein entsprechendes Feld erhalten, damit diese durchnummeriert sind.

Re: GRASP Use Case Controller

Verfasst: 3. Jan 2012 02:16
von Dennis Albrecht
Ich will mich hier mal einklinken, auch wenn meine Frage in eine etwas allgemeinere Richtung geht.

Sehe ich das richtig, dass es zur Aufgabe 1 nicht die eine richtige Lösung gibt sondern es hauptsächlich (neben der Tatsache, dass man nicht totalen Schwachsinn baut) darum geht, seine Einteilung(erste Teilaufgabe)/"geplante Vorgehensweise"(zweite Teilaufgabe) gut zu begründen?
Diese Frage bezieht sich zum einen auf die Entscheidung "Es gibt einen (Controller/Creator/Expert)" oder "Es gibt keinen (Controller/Creator/Expert)" als auch auf die verantwortlichen Klassen selbst, denen man eine Rolle zuspricht.

Anscheinend ist die Einschätzung zu den verantwortliche Klassen ja selbst für einen Dozenten reine Ansichtssache :D
eichberg hat geschrieben:ich würde bei dieser Klasse (welche den Button erzeugt, verwaltet,...) nicht von einem Use Case Controller sprechen. Aufgrund der Einfachheit des Beispiels würde ich hier aber auch nicht von der Anwendung des "Information Expert" Prinzips sprechen

Re: GRASP Use Case Controller

Verfasst: 3. Jan 2012 09:12
von jlerch
Es ist durchaus möglich, dass es mehrere gültige Lösungen gibt für Aufgabe 1 und wie Sie bereits richtig erkannt haben, ist es deshalb sehr wichtig diese zu begründen.