Feb 24 2003 91.3913 R. McFadyen 1
From the Merriam-Webster’s online dictionary (www.m-w.com):
Main Entry: an·thro·po·mor·phismPronunciation: -"fi-z&mFunction: nounDate: 1753: an interpretation of what is not human or personal in terms of human or personal characteristics : HUMANIZATION
Anthropomorphism
Feb 24 2003 91.3913 R. McFadyen 2
Anthropomorphism
Anthropomorphism: Object-oriented programming
works like human organizations. Each object will
communicate with another one by sending messages. So
the software objects work by just sending those messages.
Feb 24 2003 91.3913 R. McFadyen 3
Responsibility-Driven Design (RDD)
• Detailed object design is usually done from the point of view of:
– Objects have responsibilities
– Objects collaborate
– Similar to how we conceive of people
• In RDD we do object design such that we will ask questions such as:
– What are the responsibilities of this object?
– Who does it collaborate with?
Feb 24 2003 91.3913 R. McFadyen 4
Figure 3.1 on page 31 - Architectural Layers
Feb 24 2003 91.3913 R. McFadyen 5
Sample Problem 1
• What object should receive this message?
• How should objects interact to fulfill the request?
???
Presentation
ApplicationLogic
Video Store
Record Rental
Video ID
...
...
...
... ...
Clerk
appLogicRequest()
Now what happens?
• How do we justify out decision?
Feb 24 2003 91.3913 R. McFadyen 6
Sample Problem 2
• How should the objects interact in order for changes in the data to be reflected in the two displays?
Graphic
Display
List
Display
Data
User
• How do we justify out decision?
Feb 24 2003 91.3913 R. McFadyen 7
•idea was first put forth by Christopher Alexander (1977) in his work on architectural design principles
•a pattern is a named problem/solution pair that can be applied in new contexts
•advice from previous designers to help designers in new situations
•rules of thumb - not new ideas
•There are many books on the subject
•Design Patterns by Erich Gamma et al
•Java Design Patterns: a tutorial, by James Cooper
Patterns
Feb 24 2003 91.3913 R. McFadyen 8
• Guiding principles to help us assign responsibilities
• GRASP:
– General Responsibility Assignment Software Patterns
– Very very fundamental, simple, basic principles of object design.
GRASP Patterns Fundamental Principles of Object Design
Feb 24 2003 91.3913 R. McFadyen 9
GRASP Patterns
• Expert
• Creator
• Controller
• Low Coupling
• High Cohesion
Feb 24 2003 91.3913 R. McFadyen 10
Expert
• Assign a responsibility to the object that has the information necessary to fulfill it.
– “That which has the information, does the work.”
– Not a sophisticated idea - rather, it is common sense
– E.g., What software object calculates grand total?
• What information is needed to do this?
• What object or objects has the majority of this information.
Feb 24 2003 91.3913 R. McFadyen 11
Expert Example.
In the NextGEN POS application, it is necessary to know the grand total of a sale.
Where should that responsibility be placed?
{We will be assigning a few responsibilities in this example}
Expert suggests that we should look for a class that has the information needed to determine the grand total.
If our design is just beginning, we look at the Domain Model and bring the pertinent conceptual classes into the class model
Pages
221-226
Feb 24 2003 91.3913 R. McFadyen 12
What information is needed to determine the grand total?
It is necessary to know all the SalesLineItem instances of a sale and to sum of their subtotals. A Sale instance is aware of these … Sale is the Expert choice for having the responsibility of knowing the grand total.
Feb 24 2003 91.3913 R. McFadyen 13
Expert leads us to place the method getTotal() in Sale
Feb 24 2003 91.3913 R. McFadyen 14
A line item knows its quantity and the associated Product, so it is the expert … SalesLineItem should determine the line item subtotal
Feb 24 2003 91.3913 R. McFadyen 15
Only the Product Specification knows the price; so Product Specification needs a method ...
Feb 24 2003 91.3913 R. McFadyen 16
Creator
• What object should have the responsibility to create an X?
– Ignores special-case patterns such as Factory.
• Choose an object C, such that:
– C contains or aggregates X
– C closely uses X
– C records instances of X objects
– C closely uses X objects
– C has the initializing data for X
Feb 24 2003 91.3913 R. McFadyen 17
Example: Who should be responsible for creating a SalesLineItem? Since Sale “contains” SalesLineItems, Creator suggests Sale as the candidate for this responsiblity
Feb 24 2003 91.3913 R. McFadyen 18
:Register
:SalesLineItem
makeLineItem(qty)
create(qty)
:Sale
We assign the responsibility of creating a SalesLineItem to Sale – Sale will have a method makeLineItem
Feb 24 2003 91.3913 R. McFadyen 19
???
Presentation
ApplicationLogic
Video Store
Record Rental
Video ID
...
...
...
... ...
Clerk
appLogicRequest()
What object should this be?
What object in the domain (or application layer) receives requests for work from the UI layer?
Controller
Feb 24 2003 91.3913 R. McFadyen 20
Basic Principle: Interface objects should not have responsibility for handling system events
Assign responsibility to a Controller, an object in the application/domain layer. Choose, or invent, an object in the application layer for this.
Controller: a non-user interface object responsible for receiving or handling a system event.
In the Process Sale Use Case, there are several system events:
makeNewSale, enterItem, endSale, makePayment
Feb 24 2003 91.3913 R. McFadyen 21
makeNewSale
enterItem
endSale
makePayment
Part of Figure 9.1
System Operations
Feb 24 2003 91.3913 R. McFadyen 22
In general there are two candidates:– An object whose name reflects the use case.
• e.g. ProcessSaleHandler
– An object whose name reflects the overall server, business, or large-scale entity.
• A kind of “façade” object• e.g. Register, Store, Cashier
Choose, or invent, an object in the application layer for this.
Feb 24 2003 91.3913 R. McFadyen 23
Other choices are Store and Cashier
Register was chosen over store as it is conceptually closer to the system event
Register was chosen over Cashier as it is really an actor the runs the Register
Thus Register is the logical choice
Feb 24 2003 91.3913 R. McFadyen 24
Figure 16.16 Allocating System Operations
Register has been chosen to handle all system operations
Ch 20 shows the code for this
Use Case handlers are chosen
Feb 24 2003 91.3913 R. McFadyen 25
public void endSale ( ){sale.becomeComplete();}public void enterItem ( String id, int quantity ){ProductSpecification spec = catalog.getSpecification( id );sale.makeLineItem( spec, quantity );}public void makeNewSale ( ){sale = new Sale();}public void makePayment (Money cashTendered ){sale.makePayment( cashTendered );}
System event handling in Register
The Controller doesn’t do
much … delegates work to
other objects … it receives
the request & coordinates
fulfillment
We examine the code just
to get an idea of its
organization
Feb 24 2003 91.3913 R. McFadyen 26
The Controller pattern promotes reuse
•UI code is not intertwined with system event code
•UI can be replaced
•Multiple UIs could be utilized
When a legal sequence of operations must occur, state information must be kept … the Controller object is an excellent choice for this information
Feb 24 2003 91.3913 R. McFadyen 27
Every business system should have a controller
A controller is class whose job it is to coordinate the system events
The controller sees to it the messages are sent to the correct objects in the model – it delegates
The reason to have a controller is to separate the business model from the visual logic called a view
This is often called a MVC (Model View Controller) separation
Feb 24 2003 91.3913 R. McFadyen 28
Advantage - is that the changes to the model do not affect the GUI (view) logic
Advantage - is that the changes to the GUI (view) do not affect the model logic – could have multiple GUIs – GUI is replaceable
It provides a buffer between the visual (view) and the business logic (model)
Feb 24 2003 91.3913 R. McFadyen 29
Figure 16.7 - desirable coupling of interface layer to domain layer
Feb 24 2003 91.3913 R. McFadyen 30
Low CouplingHigh Cohesion
We use the same example, “creating a payment”, for both of these patterns.
Both patterns happen to suggest the same collaboration
Feb 24 2003 91.3913 R. McFadyen 31
Low Coupling
• When we need to assign a responsibility to a class, we should do so such that coupling remains low.
• Coupling: a measure of how strongly one element is connected to, has knowledge of, or relies on other elements.
• Low coupling: not dependent on too many other elements
• High coupling results in
– classes that are harder to understand in isolation
– changes to related classes force local changes
– classes that are harder to reuse
Feb 24 2003 91.3913 R. McFadyen 32
Low Coupling
• Example
Assume we need to create a Payment instance … what class should do this?
Feb 24 2003 91.3913 R. McFadyen 33
Creator pattern suggests Register
Figure 16.9 Register creates Payment (Collaboration diagram)
Feb 24 2003 91.3913 R. McFadyen 34
An alternative design is given in Figure 16.10
Which of the two designs, figures 16.9 and 16.10, supports lower coupling?
Feb 24 2003 91.3913 R. McFadyen 35
High Cohesion
• How do we assign responsibilities so that cohesion remains high?
• Cohesion: a measure of how strongly related and focused the responsibilities of an element are.
– a measure of how single purpose the attributes and behavior within a class are
– Better that attributes and behavior in classes be related.
• A class with highly related responsibilities and which does not do excessive amounts of work has high cohesion
Feb 24 2003 91.3913 R. McFadyen 36
High Cohesion
•When we need to assign a responsibility to a class, we should do so such that cohesion remains high
•cohesion: a measure of how strongly related and focussed the responsibilities of an object are.
–a measure of how single purpose the attributes and behavior within a class are
–It is better that attributes and behavior in classes be related.
Feb 24 2003 91.3913 R. McFadyen 37
High Cohesion
•Rule of Thumb (ROT): A class with high cohesion has a relatively small number of methods, with highly related functionality, and does not do too much work … it collaborates with others to get work done.
•Low cohesion results in classes that
–are hard to comprehend
–hard to reuse–hard to maintain
–delicate - constantly affected by change
Feb 24 2003 91.3913 R. McFadyen 38
High Cohesion
•ExampleAssume we need to create a Payment instance … what class should do this?
Feb 24 2003 91.3913 R. McFadyen 39
First solution given in Figure 16.11 (note this Sequence Diagram represents the same logic as the Collaboration diagram in Figure 16.9)
Feb 24 2003 91.3913 R. McFadyen 40
Figure 16.12 gives a second solution (note this Sequence Diagram represents the same logic as the Collaboration diagram in Figure 16.10)
Which solution supports higher cohesion for Register?
Feb 24 2003 91.3913 R. McFadyen 41
Note, when considering which class to assign the responsibility of creating a payment, the text arrives at the same solution when applying both principles