Software Construction

Design Patterns
Maryam Mir
[email protected]
Responsibilities
• Deciding what methods belong where, and how the objects should interact,
is most important
• The GRASP patterns are a learning aid in understanding essential object
design
• GRASP stands for General Responsibility Assignment Software Patterns
• UML defines Responsibility as
• “a contract or obligation of a class”
• Responsibilities are related to the obligations of an object in terms of its
behavior
• Responsibilities are of two types offers a common way to speak about
• Doing abstract concepts
• Knowing

3
Responsibilities and Methods

• Doing responsibilities of an object include

• Doing something itself such as creating an object or doing a calculation
• Initiating action in other objects
• Controlling and coordinating activities in other objects

• Knowing responsibilities of an object include

• knowing about private encapsulated data
• Knowing about related objects
• Knowing about things it can derive or calculate

4
Responsibilities and Methods
• Examples of Responsibilities
• A Sale is responsible for creating SalesLineItem instances (doing)
• A Sale is responsible for knowing its total (knowing)

• Responsibilities are assigned during object design

• Responsibility is not the same thing as a method
• methods are implemented to fulfill responsibilities

• Responsibilities are implemented using methods that either act

alone or collaborate with other methods and objects

5
Responsibilities and Methods
• Example: Collaborating with other objects
• The class Sale might define one or more methods to know its
total (say a getTotal method). To fulfill that responsibility, the
Sale may collaborate with other objects e.g. sending a
getSubTotal message to each SalesLineItem object

6
Responsibilities and Interaction Diagrams
• Creation of interaction diagrams need fundamental principles
(called Patterns) for assigning responsibilities to objects
: Sale

makePayment(cashTendered)
create(cashTendered)
: Payment

implies Sale objects have a

responsibility to create Payments

Interaction diagrams show choices in assigning responsibilities

to objects
7
 Patterns
•A Pattern is a named description of a problem and solution that can be
applied to assign responsibilities
•Patterns provide guidance for how responsibilities should be assigned
to objects

Pattern Name: Information Expert

Solution: Assign a responsibility to the class that has the
information needed to fulfill it
Problem it Solves: What is a basic principle by which to assign
responsibilities to objects?

8
GRASP Patterns
•First five GRASP patterns
• Information Expert
• Creator
• High Cohesion
• Low coupling
• Controller

•There are other patterns as well, but these address very

basic, common questions and fundamental design issues

9
Information Expert
• Problem
• What is a general principle of assigning responsibilities to
objects?

• Solution
• Assign a responsibility to the information Expert – the class that
has the information necessary to fulfill the responsibility

10
Information Expert
• Problem Explanation
• A design model may define hundreds of software classes and an
application may require hundreds of responsibilities to be fulfilled
• When the interactions between objects are defined, we make
choices about the assignment of responsibilities to software classes
• If responsibility assignment is done well
• Systems tend to be easier to understand, maintain and extend and
there is more opportunity to reuse components in future applications

11
 Information Expert - example

• In the NextGenPOS application, some class needs to

know the grand total of a sale
• Start assigning responsibilities by clearly stating the
responsibility
• Who should be responsible for knowing the grand total of a Sale?

• By Information Expert we should look for the class

that has the information needed to determine the
total
12
Information Expert - Example cont…

Sale

date
time

1
Contains

1.. *
Product
Sales Specification
LineItem * Described-by
1
description
quantity price
itemID

13
Information Expert
• Example
• What Information is needed to determine the grand
total?
• It is necessary to know about all the SalesLineItem instances of a
sale and the sum of their subtotal
• Sale class contains this information, therefore suitable for this
responsibility i.e. getTotal
• It is an Information Expert for this work

14
Information Expert – Example cont…
• What information is needed to determine the SlaesLineItem
subtotal?

 SalesLineItem.quantity and SalesLineItem.price

 Now
 SalesLineItem knows its quantity and it is associated with
ProductSpecification
 By Information Expert, SalesLineItem should determine
subtotal

15
Information Expert - Example cont…

• For knowing and answering its subtotal a SalesLineItem needs

to know the product price

• ProductSpecification is expert for price of a salesLineItem

• A message must be sent to it asking for price

16
Information Expert - Benefits

•Information Encapsulation is maintained

• As objects use their own information to fulfill tasks

•Low coupling is promoted

• More robust and maintainable systems

•High cohesion is promoted

• Behavior is distributed across classes that have the information

•Related Patterns (to be discussed)

• Low Coupling
• High Cohesion
17
Coupling
• Coupling is a measure of how strongly one element is
connected to, has knowledge of, or relies on other elements.

• An element with low or weak coupling is not dependent on

too many other elements

• Elements include classes, subsystems, systems etc.

18
Coupling

• A class with high or strong coupling relies on many

other classes
• Some classes may be undesirable; and suffer from
following problems
• Changes in related classes force local changes
• Harder to understand in isolation
• Harder to reuse because its use requires the additional
presence of the classes on which it is dependent.

19
Low Coupling
• Problem
• How to support low dependency, low change impact and
increased reuse?

• Solution
• Assign responsibilities so that coupling remains low

20
Low Coupling - Example
• Consider the following partial diagram

Payment Register Sale

 Assume we have a need to create a payment instance

and associate with the sale
 What class should be responsible for this?

21
Low Coupling-Example cont…
• Register records a payment in real world domain

• Creator pattern suggests Register for creating payment

• The Register instance could then send an addPayment message

to Sale, passing along the new Payment as parameter.

• Interaction diagram reflecting this would be…

22
 Low Coupling

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

2: addPayment(p)
:Sale

Note that Payment instance is explicitly named ‘p’ so

that in message2 it can be referenced as parameter

23
Low Coupling
• An alternative solution

makePayment() : Register 1: makePayment() :Sale

1.1. create()

:Payment

24
Low Coupling – Example cont…
• Which design based on assignment of responsibilities supports low coupling?

• Sales must be coupled with payment

• In Diagram1, in which the Register creates the payment, adds coupling of payment

• In Diagram2 Sale does the creation of payment and it does not increase coupling

• From the point of view of Coupling Design2 is preferable

• An example, where two patterns suggests different solutions

25
Low Coupling - Benefits
• Not affected by changes in other components

• Simple to understand in isolation

• Convenient to reuse

26
Low Coupling

In Practice the level of coupling alone can’t be

Considered in isolation from other principles
Such as Information Expert and high cohesion.
Nevertheless It is one factor to consider
in improving a design

27
Cohesion
• Cohesion is a measure of how strongly related and focused
the responsibilities of an element are.
• An element with highly related responsibilities and which does
not do a tremendous amount of work, has high cohesion.
• A class with low cohesion does many unrelated things, or
does too much work.
• Such classes are undesirable; they suffer from many problems

28
Cohesion
• Low Cohesion classes suffer from problems like;
• Hard to comprehend (understand)

• Hard to reuse

• Hard to maintain

• Delicate; constantly affected by change

• Low cohesion classes often have taken on responsibilities

that should have been delegated to other classes

29
High Cohesion
• Problem
• How to keep complexity manageable?

• Solution
• Assign a responsibility so that cohesion remains high

30
High Cohesion
• Example (same example problem used in Low Coupling
pattern can be analyzed for High Cohesion)
• We have a need to create a Payment instance and associate it with Sale.
• Which class should be responsible for it?
• As discussed earlier, in real world domain Register records Payment
• Creator Pattern suggests Register as a candidate class for creating a
Payment instance
• Register instance could then send an addPayment message to the Sale
passing new Payment instance as a parameter

31
High Cohesion - Example
• Register Creates Payment

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

2: addPayment(p)
:Sale

32
 High Cohesion
Register Creates Payment

• This single system event does not make Register class incohesive

• But there exists many related system events (e.g. fifty system
operations/events)

• If Register is assigned responsibility for all these system operations; it may

become incohesive object

• Second design ( next example ) supports high cohesion and low coupling

33
 High Cohesion
• Sale Creates Payment
: Register : Sale

makePayment()
makePayment()
create()
: Payment

Since the second design supports both high cohesion and low coupling, it
is preferable
34
High Cohesion

In Practice, the level of cohesion alone can

not be considered in isolation from other
responsibilities and other principles such
as Information Expert and Low Coupling

35
High Cohesion
• Functional Cohesion
• When the elements of a component (a class) “all work together to
provide some well-bounded behavior” [Grady Booch 94]

• Scenarios that illustrate varying degrees of functional cohesion

• Very Low Cohesion
• Low Cohesion
• High Cohesion
• Moderate Cohesion

36