Anthropomorphism

1
Anthropomorphism
From the Merriam-Websters online dictionary
(www.m-w.com) Main Entry anthropomorphismP
ronunciation -"fi-zmFunction nounDate
1753 an interpretation of what is not human or
personal in terms of human or personal
characteristics HUMANIZATION
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.
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?

4
Figure 3.1 on page 31 - Architectural Layers
5
Sample Problem 1

• What object should receive this message?
• How should objects interact to fulfill the
  request?

• How do we justify out decision?

6
Sample Problem 2
Graphic Display
List Display
Data
User

• How should the objects interact in order for
  changes in the data to be reflected in the two
  displays?

• How do we justify our decision?

7
Patterns

• 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 examples
• Design Patterns - Erich Gamma et al
• Java Design Patterns a tutorial - James Cooper
• Design Patterns Java Workbook - Steven John
  Metsker
• Data Access Patterns - Clifton Nock
• Patterns of Enterprise Application Architecture
  Martin Fowler

8
GRASP Patterns Fundamental Principles of Object
Design

• Guiding principles to help us assign
  responsibilities
• GRASP
• General Responsibility Assignment Software
  Patterns
• Very very fundamental, simple, basic principles
  of object design.

9
GRASP Patterns

• Expert
• Creator
• Controller
• Low Coupling
• High Cohesion

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.

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
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
their subtotals. A Sale instance is aware of
these Sale is the Expert choice for having the
responsibility of knowing the grand total.
13
Expert leads us to place the method getTotal() in
Sale
14
A line item knows its quantity and the associated
Product, so it is the expert SalesLineItem
should determine the line item subtotal
15
Only the Product Specification knows the price
so Product Specification needs a method ...
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

17
Example Who should be responsible for creating a
SalesLineItem? Since Sale contains
SalesLineItems, Creator suggests Sale as the
candidate for this responsiblity
18
Register
Sale
makeLineItem(qty)
SalesLineItem
create(qty)
We assign the responsibility of creating a
SalesLineItem to Sale Sale will have a method
makeLineItem
19
Controller
What object in the domain (or application layer)
receives requests for work from the UI layer?
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
21
Part of Figure 9.1
makeNewSale enterItem endSale makePayment
System Operations
22
Choose or invent an object in the application
layer for this.

• 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

23

• Register, Store, Cashier
• Register is chosen in the text

24
Figure 16.16 Allocating System Operations
Register has been chosen to handle all system
operations Ch 20 shows the code for this
If Use Case handlers were chosen
25
System event handling in Register
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 )
We examine the code just to get an idea of its
organization
The Controller doesnt do much delegates work
to other objects it receives the request
coordinates fulfillment
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 a Controller
  object is an excellent choice for this information

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

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)

29
Figure 16.7 - desirable coupling of interface
layer to domain layer
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
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

32
Low Coupling

• Example
• Assume we need to create a Payment instance
  what class should do this?

33
Creator pattern suggests Register
Figure 16.9 Register creates Payment
(Collaboration diagram)
34
An alternative design is given in Figure 16.10
Which of the two designs, figures 16.9 and 16.10,
supports lower coupling?
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.
• Cohesion is 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.
• A class with highly related responsibilities and
  which does not do excessive amounts of work has
  high cohesion

36
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

37
High Cohesion

• Example
• Assume we need to create a Payment instance
  what class should do this?

38
First solution given in Figure 16.11 (note this
Sequence Diagram represents the same logic as the
Collaboration diagram in Figure 16.9)
39
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?
40
Note, when considering which class to assign the
responsibility of creating a payment, the text
arrives at the same solution when applying both
principles