Software Design and

Architecture
WEEK 3
GRASP PATTERNS
COURSE INSTRUCTOR:
TAZZAINA MALIK
Design Patterns

2
What are design patterns?
▪ Principles and solutions codified in a structured format describing a
problem and a solution
▪ A named problem/solution pair that can be applied in new contexts
▪ It is advice from previous designers to help designers in new situations
▪ Design patterns are related to the two main artifacts 1. Class Diagram
and 2. Sequence Diagram.
▪ Design patterns highlights the best programming practices. These
patterns discriminate a good designer/coder from a naïve designer
coder
Which one will you classify as
a pattern?

4
5
Patterns, Patterns every where..

▪ Mature engineering disciplines have

handbooks describing successful solutions
to known problems
▪ Automobile designers don't design cars from
scratch using the laws of physics
▪ Instead, they reuse standard designs with
successful track records, learning from experience

6
Patterns and Software…. What's
the connection?
▪ Software too is an engineered product
▪ Recurring design decision problems
▪ Repeated solution application
▪ Problem – Solution pair = Software Design Pattern
▪ Developing software from scratch is also expensive
▪ In software engineering, a design pattern is a general reusable
solution to a commonly occurring problem in software design.

7
Responsibility Driven Design
Responsibility is a contract or obligation behavior
of an object.
“After identifying your requirements and creating a
domain model, then add methods to the software
classes, and define the messaging between the
objects to fulfill the requirements.”
But how?
What method belongs where?
How should the objects interact?
This is a critical, important, and non-trivial task
8
General Responsibility
Assignment Patterns
(GRASP)
GRASP
1. Information Expert
2. Creator
3. Low Coupling
4. High Cohesion
5. Controller
6. Polymorphism
7. Pure Fabrication
8. Indirection
9. Law of Demeter

10
Creator
Doing Responsibility (Creating an object)
Problem:
Assign responsibility for creating a new instance of
some class?
Solution:
Determine which class should create instances of a
class based on the relationship between potential
creator classes and the class to be instantiated.

11
Creator Pattern:

12
Creator Pattern:

13
Example:

14
 Example:
Who is responsible for creating SalesLineItem objects?
Look for a class that aggregates or contains SalesLineItem objects.

Sale

date
time

mak eLineItem (quanti ty ) :S ale S al e

date
time
Contain
N e w m ethod
1: create(quantity)
makeLineItem(
s
total() 1..*
:SalesLineItem Product
Sales Specification
LineItem * Described-
by description
quantity price
UPC

15
Creator Pattern

16
Who creates the Squares?

17
How does Create pattern develop
this Design Class Diagram (DCD)?

Board has a composite aggregation relationship with Square

• I.e., Board contains a collection of Squares

18
How does Create pattern lead to
this partial Sequence diagram?

19
Information expert

20
Information Expert
Knowing responsibility
Problem:
What is the most basic principle by which
responsibilities are assigned in object-oriented
design?
Solution:
Assign a responsibility to the class that has the
information necessary to fulfil the responsibility.

21
Expert: Example
Who is responsible for knowing the grand
total of a sale in a typical Point of Sale
application? Sale

date
time

Contain
s
1..*
Product
Sales Specification
LineItem * Described-
by description
quantity price
UPC

22
Expert: Example
Need all SalesLineItem instances and their
subtotals. Only Sale knows
this, so Sale is the information expert.
Hence
t : = total() :Sale Sale

date
time
New method total()

23
24
Information Expert:

25
Information Expert Benefits
1. Maintain encapsulation of information
2. Promotes low coupling
3. Promotes highly cohesive classes

26
Coupling & Cohesion

27
What is Coupling…?
Coupling is a measure of
◦ how strongly one element is connected to the
other
◦ has knowledge of
◦ or relies on other elements.

An element with low (or weak) coupling is

not dependent on too many other elements.

28
Coupling and Cohesion:

29
Coupling and Cohesion:

30
31
Coupling and Cohesion:

32
Breakdown

33
 Point to Ponder…?
In practice the level of coupling
alone can't be considered in
isolation from other principles
such as Information Expert and
High Cohesion.

*Low coupling is a principle to

keep in mind during all design
decisions.
34
How Information Expert Help?
In practice the level of cohesion alone can't be
considered in isolation from other responsibilities and
other principles such as Information Expert and Low
Coupling.

*High cohesion is a principle to keep in mind during all

design decisions.

35
Example:
High Cohesion ?
Who has responsibility to create a payment?
1.Post

makePayment() 1: create()
:Register p : Payment

2: a d d P a y m e n t ( p )
:Sale

looks OK if makePayement considered in isolation, but

adding more system operations, Register would take on
more and more responsibilities and become less
cohesive.

37
 High Cohesion:
Giving responsibility to Sale supports higher cohesion in Post, as well as low coupling.

m a k e P a ym e n t ( ) :Register 1: m a k e P a ym e n t ( ) :S ale

1.1. create()

: P a ym e n t

38
Low Coupling Pattern:
Name: Low Coupling
Problem: How to reduce the impact of change
and encourage reuse?
◦ How to support
◦ Low dependency,
◦ Low change impact
◦ Increased reuse.
Solution: Assign a responsibility so that
coupling (linking classes) remains low.

39
Coupling Indications?
High Cohesion Pattern:

41
Why High Cohesion?
How does the design on right promote high
cohesion?

43
Example
of Low
Cohesion:

44
Example of High Cohesion:
:Student :DBController

45
 Cohesiveness Levels:
Very Low Cohesion: A Class is solely responsible for many
things in very different functional areas

Low Cohesion: A class has sole responsibility for a complex

task in one functional area.

High Cohesion: A class has moderate responsibilities in one

functional area and collaborates with classes to fulfil tasks.

46
Why high Cohesion..?
1. Modular Design, modularity is the
property of a system that has been
decomposed into a set of cohesive and
loosely coupled modules.
2. Bad cohesion usually results in bad
coupling and vice versa.

47
Controller

48
Controller Pattern:

49
 Good design
- presentation layer decoupled from problem domain

presses button

: Cashier

actionPerformed( actionEvent )

UI Layer :SaleJFrame

system operation message

enterItem(itemID, qty)

Which class of object should be responsible for receiving this

Domain system event message?
: ???
Layer
It is sometimes called the controller or coordinator. It does not
normally do the work, but delegates it to other objects.

The controller is a kind of "facade" onto the domain layer from

the interface layer.
50
Good design
- presentation layer decoupled from problem
domain

presses button

: Cashier

actionPerformed( actionEvent )

system operation message

UI Layer :SaleJFrame

1: enterItem(itemID, qty)

controller

Domain Layer 1.1: makeLineItem(itemID, qty)

:Register :Sale

51
 Controller

• A controller is a non-UI object responsible for

receiving/handling a system event.
• A controller defines the method for the system operations
52
Bloated Controller

53
Extended Patterns
- Polymorphism
- Pure Fabrication
- Indirection
- Protected Variation
Polymorphism
GRASP
What is Polymorphism?
▪ Polymorphism is derived from 2 Greek words: “poly”
and “morph”. Poly means many, morph means forms.
▪ So, Polymorphism means many forms.
▪ Polymorphism is a concept by which we can perform
a single action in many ways
▪ There are two types of polymorphism. Compile time
polymorphism and runtime polymorphism.
▪ Here we will focus on runtime polymorphism

56
Polymorphism:

57
Example:

58
Example:

59
Polymorphism:

60
Polymorphism Example:

61
Polymorphism Example:

62
Example:

63
Pure Fabrication
GRASP
 Pure Fabrication:

Create a class that is not found in your conceptual model, one that
does not necessarily have a business meaning to the business
entity/person
65
Example:

66
Pure Fabrication:

67
Indirection
MOST PROBLEMS IN COMPUTER SCIENCE CAN BE
SOLVED BY ANOTHER LEVEL OF INDIRECTION

68
Indirection:

69
70
Protected Variation
GRASP
PROTECTED VARIATION
Problem : How to design objects, subsystems, and systems so that the
variations or instability in these elements does not have an undesirable
impact on other elements.
Solution: identify points of predicted variation or instability; assign
responsibilities to create a stable interface around them
*Interface (abstraction) in the broader sense-not just Java interface
- Example: ITaxCalculatorAdaptor
*Instability does not mean “crashy”. It means prone to change or evolve
Many other patterns and concepts in software design derive from this,
including data encapsulation, polymorphism, data-driven designs,
interfaces, virtual machines, etc.

72
Protected Variation

73
74
 Design Patterns are
disconnected?
▪The answer is NO
▪Design patterns are not disconnected to each
other, they all are interconnected
▪One pattern is related to other pattern(s) as well
▪With the help of Polymorphic behavior, we were having
low coupling
▪With the help of low coupling, we were getting high
cohesion
▪With the help of Information Expert, we were getting
highly cohesive elements
▪Creator was affecting high cohesion

75
THANK YOU

76