Disclaimer: Dieser Thread wurde aus dem alten Forum importiert. Daher werden eventuell nicht alle Formatierungen richtig angezeigt. Der ursprüngliche Thread beginnt im zweiten Post dieses Threads.
Homework: Consolidated Domain Model
Hi!
I (and some others I have heard) am not exactly sure what we should do in the exercise for tomorrow. We have three required tasks to do, which are:
- Substructure class interfaces into collaborations
- Document (by comment) collaborations in class interface
- Document collaborations in homework submission
While I get Task #2 and #3 which are just comments and an UML with explanation I don’t quite get Task #1.
I get what collaborations are (mostly fields in classes), but what about the whole substructuring?
Does substructuring (in this case) mean creating packages for collaborating classes?
Sounds to me that this weeks homework is more or less “Document and if you want code some lines.”
What do you think?
Hi,
Task 1 is the precondition for Task 2 and 3.
A collaboration specification/description (sometimes abbreviated as just collaboration) (synonyms role model from homework reading) is a description of how objects work together for a particular task, for example, serialization (Serializer pattern), state change notification (Observer pattern), tree structure maintenance (Composite pattern). Many collaborations are actually applications of design patterns (but not all). The example collaborations that I just gave you do not capture the primary purpose but rather realize secondary issues. The primary purpose of a class is typically expressed by a “simple” client/service collaboration: Some domain specific functionality. That client/service collaboration is typically not a design pattern application. (Though people have started documenting domain-specific patterns and so there are now “analysis patterns” or “domain patterns” that might capture the generalizable aspects of such collaborations.
In programming, the methods of a class focussed on the purpose of the collaboration constitute the role that instances of the class can play. In a simple Observer pattern application, there is the Observer role with methods update(…) about state changes and there is the Subject role with methods register(Observer) etc. Such methods really define roles, that is partial interfaces. You can easily have a class that provides both the Observer and Subject roles and hence both sets of methods within the same class. Different instances of the same class (or subclasses thereof) can observe each other. An instance of the class can even observe itself then. If this discussion is confusing, please read the Observer pattern first (see Course Reader or Wikipedia0.
Each collaboration, of which there may be many that a class defines its instances participate in, has state associated with it. Abstract state you can recognize by getters and setters. Concrete state would be actual class fields that the getters and setters work on. Because collaborations have a single purpose, if there was no interaction between collaborations, the class would fall apart. However, in the method implementations, typically by way of fields, your control flow jumps between collaborations. For example, using the client/service collaboration, you set a value to YourPhoto class. Maybe YourPhoto class also participates in an application of the Observer pattern, and someone registered interest in the field you just changed. Then, the implementation of your setter needs to cross over from the client/service collaboration into the Observer collaboration and notify the registered observers about the state change.
Once you have an understanding of the collaborations your classes participate in (many can be found in the superclasses), you can restructure your Java interfaces and classes in such a way that you group methods that belong to one role implementation together. You may find that some methods serve multiple purposes and you may want them to show up in multiple different roles. This may indicated a convoluted design (but doesn’t have to). You might want to put such methods into a separate section and explain that multiple roles from collaborations use it. You might even have different fronts to these methods in roles that delegate to one central method.
Hope this helps. It is important that you solve Task 1 first before you get to Task 2 and 3.
Dirk
1 Like
Observer pattern: http://sourcemaking.com/design_patterns/observer
So we should analyze our classes identifying those that are part in multiple collaborations and try to dissect them either into multiple classes or by separating them in another way.
OK.
Alles, was ich eben nochmal erlaeutert hatte, ist im Prinzip auf Folie 10 im Foliensatz ADAP B10 dargestellt. Das ist ein guter Startpunkt fuer die Hausaufgabe
1 Like