Object-Oriented Design Part 2
http://flic.kr/p/btp5ZK
Frames object design as deciding
• How to assign responsibilities to objects
• How objects should collaborate
– What role each each object should play in a collaboration
http://flic.kr/p/btp5ZK
Responsibility-Driven Design
What is meant by responsibilities
An object’s obligations (and thus behavior)
Two types:
•Doing responsibilities, e.g.:
–
–
–
–
Creating an object
Calculating something
Initiating action on other objects
Coordinating activities among other objects
•Knowing responsibilities, e.g.:
– Knowing about data
– Knowing about related objects
– Knowing about things it can derive or calculate
Domain Model attributes inspire
knowing responsibilities
Analysis
Design
Register knows its ID
Sale knows its time
What is meant by collaboration?
Objects interact (via messages) to fulfill responsibilities
• Example:
Register collaborates
with Sale and Payment
to process a payment
(its responsibility)
Responsibilities vary in granularity
• “Big” responsibilities may require collaborations
of many objects
• “Small” responsibilities may be fulfilled by a
single object
How to assign
responsibilities and
design collaborations?
• No mechanical method
– Requires expert human
judgment!
• But there’s hope: patterns!
http://flic.kr/p/4tTsQe
Patterns
• Repeatable solution for a commonly occurring
software problem
• Codify existing tried-and-true knowledge
• Provide vocabulary
Point of Sale Example
• Think of a cashier’s register
–
–
–
–
Cashier scans or manually enters the price of items
All items sold make up a sale
Payment is received, change is given
A receipt is generated
POS Design Question
What object should be responsible for
creating a SalesLineItem?
Creator Pattern
Assign class B responsibility of creating instances of
class A if 1+ of the following:
•B “contains” A
•B records A
•B closely uses A
•B has initializing data for A
– B is an expert with respect to creating A
POS Design Question
The Creator Pattern says
that Sale should create
SalesLineItem
What object should be responsible for creating a
SalesLineItem?
How a Sale object might create
a SalesLineItem object
: Register
: Sale
POS Design Question
What object should be responsible for
knowing the grand total of a sale?
Information Expert Pattern
Assign a knowing responsibility to the class that has the
information necessary to fulfill the responsibility
POS Design Question
The Information Expert
Pattern says that Sale should
know the grand total
What object should be responsible for
knowing the grand total of a sale?
How Sale might calculate the grand total
Sale will need a method for
computing the total
How Sale might calculate the grand total
Sales will get the subtotal
from each SalesLineItem
How Sale might calculate the grand total
SalesLineItem will need to get the
price from ProductDescription
How Sale might calculate the grand total
These three objects
collaborate to compute
the grand total
Each one must fulfill its
own set of responsibilities
POS Design Question
Assume we need to create a Payment instance
and associate it with a Sale instance
What class should be responsible for this?
One possible design: Register creates Payment
Another possible design: Sale creates Payment
Which design is better?
Low Coupling Pattern
Assign responsibilities so that coupling stays low
Coupling: measure of how strongly one element
• is connected to others
• has knowledge of others
• relies on others
Common types of coupling in OO languages
Class C is coupled to class D if
• C has instance variable that refers to D
• C invokes method/function of D
• C method parameter or local variable references D
• C is direct or indirect subclass of D
• C implements interface D
Problems with high coupling
Given class C highly coupled to class D:
• Changes in D may force changes in C
• Harder to understand C in isolation
• Harder to reuse C because of dependencies on D
Which design has lower coupling?
Assuming Sale will eventually need to be coupled with Payment
First design adds extra coupling between
Register and Sale so second design has
lower coupling
Critique: Other considerations may override
preference toward low coupling
• Strength of coupling should be balanced against
other design considerations
Critique: High coupling to stable/pervasive
elements is seldom a problem
• Consider coupling to Java standard libraries
Review of Key OO Concepts
• Objects/Classes
• Information Hiding – The ability to protect class contents from
external entities
– Private/Protected
• Inheritance – The ability for a class to extend and override
functionality of another class
– Generalization/Specification
• Interface – A contract of functionality other classes can
implement
• Polymorphism – The ability to create an entity that has more
than one type
Design Advice
• Inputs for your design
–
–
–
–
–
Use Cases
Sequence Diagrams
Prototypes
Dataflow Diagrams
Architecture Diagrams
Best practices
• Use known design patterns
– Creator
– Information Expert
– More to come on the next class
• Take advantage of tried-and-true libraries
– Don’t reimplement something that’s already been done
• Ex: Use known encryption libraries, they have been thoroughly
tested and much less likely to have bugs
Vision Statement
• Next week we’ll start Agile
• Everyone will create a new vision statement with a
new topic using the same specification as HW 0
• Consider a solution that lends itself to an iterative
design
• These will be due next Monday
What’s next for you?
• HW 3 is due tomorrow by midnight
• HW 4 is posted
• Think about your new vision statements