UNIT 4: GRASP-METHODOLOGICAL APPROACH TO

OBJECT DESIGN

UML vs Object Design:

Since the UML is simply a standard visual modeling language, knowing its details doesn't teach
us how to think in objects. The UML is sometimes described as a design tool but that's not
quite right.
The critical design tool for software development is a mind well educated in design principles.
It is not the UML or any other technology.

Object Design:
In object design generally we consider following things:
1. Inputs to Object Design
2. Activities of Object Design
3. Outputs of Object Design

Inputs to Object Design

The inputs to the object design are re-reading the use case text or operation contracts, scanning
the domain model, and reviewing the Supplementary Specification.
Activities of Object Design
Given one or more of these inputs, developers
a. start immediately coding (ideally with test-first development)
b. start some UML modeling for the object design
c. start with another modeling technique, such as CRC cards.
Outputs of Object Design:
An object with assigned responsibilities.

Responsibilities and Responsibility-Driven Design:

A popular way of thinking about the design of software objects and also larger-scale
components is in terms of responsibilities, roles and collaborations. This is part of a larger
approach called responsibility-driven design or RDD.

1
Prepared By: RC
In RDD, we think of software objects as having responsibilities-an abstraction of what they do.
The UML defines a responsibility as "a contract or obligation of classifier." Responsibilities
are related to the obligations or behavior of an object in terms of its role. Basically, these
responsibilities are of the following two types: doing and knowing
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 order objects
Knowing responsibilities of an object include:

 knowing about private encapsulated data

 knowing about related objects.
 knowing about things it can derive or calculate

What are Patterns?

Experienced OO developers (and other software developers) build up a repertoire of both
general principle and idiomatic solutions that guide them in the creation of software. These
principles and idioms, if codified in a structured format describing the problem and solution
and named, may be called patterns. For example, here is a sample pattern,
Pattern Name: Information Expert
Problem: What is a basic principle by which to assign responsibilities to objects?
Solution: Assign a responsibility to the class that has the information needed to
fulfill it.
In OO design, a pattern is a named description of a problem and solution that can be applied to
new contexts, ideally, a pattern advises us on how to apply its solution in varying circumstances
and considers the forces and trade-offs. Many patterns, given a specific category of problem,
guide the assignment of responsibilities to objects.
Most simply, a good pattern is a named and well-known problem/solution pair that can be
applied in new contexts with advice on how to apply it in novel situations and discussion of its
trade-offs, implementations, variations, and so forth.

GRASP:
 GRASP stands for General Responsibility Assignment Software Patterns. The name was
chosen to suggest the importance of grasping these principles to successfully design
object-oriented software.
 Guides in assigning responsibilities to collaborating objects.
 There are 9 GRASP patterns:

2
Prepared By: RC
 1. Creator
2. Information Expert
3. Low Coupling
4. Controller
5. High Cohesion
6. Indirection
7. Polymorphism
8. Protected Variations
9. Pure Fabrication

Creator
The creation of objects is one of the most common activities in an object-oriented system.
Consequently, it is useful to have a general principle for the assignment of creation
responsibilities. Assigned well, the design can support low coupling, increased clarity,
encapsulation and reusability.
Problem: Who should be responsible for creating a new instance of some class?
Solution: Assign class B the responsibility to create an instance of class A if one
of these is true.
 B contains or compositely aggregates A
 B records A
 B closely uses A
 B has the initializing data for A that will be passed to A when it is
created. Thus B is an Expert with respect to creating A.
For Example:
Consider VideoStore and Video in that store. VideoStore has an aggregation association with
Video i.e. VideoStore is the container and the Video is the contained object. So, we can
instantiate video object in VideoStore class

3
Prepared By: RC
 Fig: Partial Domain model of video store
Since a VideoStore contains (in fact, aggregations) many Video objects, the Creator pattern
suggest that VideoStore is a good candidate to have the responsibility of creating Video
instances. This leads to design of object interaction as shown in figure below.

Fig: Creating a Video

Information Export
A design model may define hundreds or thousands of software classes, and an application may
require hundreds or thousands of responsibilities to be fulfilled. During object design when the
interactions between objects are defined, we make choices about the assignment of
responsibilities to software classes. If we've chosen well, systems tend to be easier to
understand, maintain, and extend and our choices afford more opportunity to reuse components
in future applications.
By Information Expert, we should look for that class of objects that has the information needed
to determine the total.
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.
For Example:
Assume we need to get all the videos of a VideoStore. Since VideoStore knows about all the
videos, we can assign this responsibility of giving all the videos can be assigned to VideoStore
class. VideoStore is the information expert.

4
Prepared By: RC
 Figure: Example for Information Expert

Figure: Getting video details from Information Expert

Low 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. These elements include classes, subsystems, systems, and so on.
A class with high (or strong) coupling relies on many other classes. Such classes may be
undesirable. Some suffer from following problems:
 Forced local changes because of changes in related classes.
 Harder to understand in isolation
 Harder to reuse because its use requires the additional presence of the classes on which
it is dependent.

5
Prepared By: RC
Two elements are coupled, if
 One element has aggregation/composition association with another element.
 One element implements/extends other element.

Problem: How to support low dependency, low changes impact, and increased
reuse?
Solution: Assign a responsibility so that coupling remains low. Use this principle
to evaluate alternatives.
For example:

Fig: Poor Coupling

Here class Rent knows about both VideoStore and Video objects. Rent is depending on both
the classes.

Fig: Low coupling

6
Prepared By: RC
VideoStore and Video class are coupled, and Rent is coupled with VideoStore. Thus providing
low coupling.

Controller
A controller is the first object beyond the UI layer that is responsible for receiving or handling
a system operation message. It deals with how to delegate the request from the UI layer objects
to domain layer objects. When a request comes from UI layer object, Controller pattern helps
us in determining, which is that first object that receive the message from the UI layer objects.
This object is called controller object which receives request from UI layer object and then
controls/coordinates with other object of the domain layer to fulfill the request. It delegates the
work to other class and coordinates the overall activity.

Benefits
 Can reuse this controller class.
 Can use to maintain the state of the use case.
 Can control the sequence of the activities

Problem: What first object beyond the UI layer receives and coordinates (controls)
a system operation?
Solution: Assign the responsibility to a class representing one of following
choices:
 Object represents the overall system (facade controller)
 Object represent a use case, handling a sequence of operations
(session controller).

For example:
Figure below shows the system with controller.

Fig: Controller Object

7
Prepared By: RC
Bloated Controllers
Controller class is called bloated, if
 The class is overloaded with too many responsibilities.
Solution – Add more controllers
 Controller class also performing many tasks instead of delegating to other class.
Solution – controller class has to delegate things to others.

High Cohesion
In terms of object design, cohesion (or more specifically, functional cohesion) is a measure of
how strongly related and focused the responsibilities of an element. An element with highly
related responsibilities that does not do a tremendous amount of work has high cohesion.
These elements include classes, subsystems and so on.
A class with low cohesion does many unrelated things or does too much work. Such classes
are undesirable, they suffer from the following problems.
 Hard to comprehend
 hard to reuse
 hard to maintain
 constantly affected by change.
Benefits
 Easily understandable and maintainable.
 Code reuse
 Low coupling

Problem: How to keep object focused, understandable, and manageable, and as a

side effect, support Low Coupling?
Solution: Assign a responsibility so that cohesion remains high. Use this to
evaluate alternatives.

For example:

8
Prepared By: RC
 fig: Low cohesion
Here the student performs both display student detail as well as insert student. When we try to
do too many jobs with single object it may create poor coupling.

fig: High cohesion

In this case the Student performs only get student detail and leave the job of insertion to DB
object.

9
Prepared By: RC
Polymorphism
● Polymorphism guides us in deciding which object is responsible for handling those
varying elements.
● Benefits: handling new variations will become easy.

Problem: How to handle alternatives based on type? How to create pluggable

software components?
Solution: When related alternatives or behaviors vary by type (class), assign
responsibility for the behavior--using polymorphic operations--to the
types for which the behavior varies.

Example for Polymorphism

 The getArea() varies by the type of shape, so we assign that responsibility to the subclasses.
 By sending message to the Shape object, a call will be made to the corresponding sub class
object – Circle or Triangle.

Fig: Polymorphism in Shape

Pure Fabrication
● Fabricated class/ artificial class – assign set of related responsibilities that doesn't
represent any domain object.
● Provides a highly cohesive set of activities.
● Behavioral decomposed – implements some algorithm.
● Examples: Adapter, Strategy
● Benefits: High cohesion, low coupling and can reuse this class.

Problem: What object should have the responsibility, when we don’t want to
violate High Cohesion and Low Coupling or other goals but solutions
offered by Expert are not appropriate?
Solution: Assign a highly cohesive set of responsibilities to an artificial or

10
Prepared By: RC
 convenience class that does not represent a problem domain concept--
something made up, to support high cohesion, low coupling and reuse.

Example
● Suppose we Shape class, if we must store the shape data in a database.
● If we put this responsibility in Shape class, there will be many database related operations
thus making Shape incohesive.
● So, create a fabricated class DBStore which is responsible to perform all database
operations.
● Similarly logInterface which is responsible for logging information is also a good
example for Pure Fabrication.

Indirection
● Indirection introduces an intermediate unit to communicate between the other units, so
that the other units are not directly coupled.
● Benefits: low coupling
● Example: Adapter, Facade, Observer
Problem: Where to assign a responsibility, to avoid direct coupling between two
(or more) things? How to de-couple objects so that low coupling is
supported and reuse potential remains higher?
Solution: Assign the responsibility to an intermediate object to mediate between
other components or services so that they are not directly coupled.

Example for Indirection

● Here polymorphism illustrates indirection
● Class Employee provides a level of indirection to other units of the system.

Fig: Employee as indirection

11
Prepared By: RC
Protected Variation
 How to avoid impact of variations of some elements on the other elements.
 It provides a well-defined interface so that the there will be no effect on other units.
 Provides flexibility and protection from variations.
 Provides more structured design.
 Example: polymorphism, data encapsulation, interfaces
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.

Design for Visibility

Visibility is the ability of one object to see or have reference to another object. More generally,
it is related to the issue of scope. Is one resource within the scope of another? There are four
common ways that visibility can be achieved form object A to object B:
 Attribute Visibility: B is an attribute of A.
 Parameter visibility: B is a parameter of a method of A.
 Local Visibility: B is a (non-parameter) local object in a method of A.
 Global Visibility: B is in some way globally visible.
Attribute Visibility:
Attribute visibility from A to B exists when B is an attribute of A. It is a relatively permanent
visibility because it persists as long as A and B exist. This is very common visibility in Object
Oriented Systems.
For example, in a Java class definition for Register, a Register instance may have attribute
visibility to a ProductCatalog, since it is an attribute (Java instance variable) of the Register.
public class Register
{
……
private ProductCatalog catalog;
……
}
This visibility is required because in the enterItem diagram shown in Figure below, a Register
needs to send the getProductDescription message to a ProductCatalog:

12
Prepared By: RC
 Fig: Attribute Visibility

Parameter Visibility:
Parameter visibility from A to B exits when B is passed as a parameter to a method of A. It is
a relatively temporary visibility because it persists only within the scope of the method. After
the attribute visibility it is the second most common form of visibility in object-oriented
systems.
For example, when the makeLineItem message is sent to a Sale instance, a ProductDescription
instance is passed as a parameter. Within the scope of the makeLineItem method, the Sale has
parameter visibility to a ProductDescription. Figure below shows this.

Fig: Parameter Visibility

Local Visibility:
Local visibility from A to B exists when B is declared as a local object within a method of A.
It is a relatively temporary because it persists only within the scope of the method. After
parameter visibility, it is the third most common form of visibility in object-oriented systems.
Two common means by which local visibility is achieved are:
 Create a new local instance and assign it to a local variable.
 Assign the returning object from a method invocation to a local variable.

13
Prepared By: RC
For example, the second variation (assigning the returning object to a local variable) can be
found in the enterItem method of class Register as shown in figure below.

Fig: Local Visibility

Global Visibility:
Global visibility from A to B exists when B is global to A. It is a relatively permanent visibility
because it persists as long as A and B exist. It is the least common form of visibility in object-
oriented systems.
One way to achieve global visibility is to assign an instance to a global variable, which is
possible in some languages, such as C++, but not others, such as Java.
The preferred method to achieve global visibility is to use the Singleton pattern.

The Gang-of-Four Patterns

 A seminal and extremely popular work that presents 23 patterns useful during object
design.
 Since the book was written by four authors, these patterns have become known as the
"Gang-of-Four"—or "GoF"—patterns.
 Some of the GoF patterns are:

Adapter:
Polymorphism pattern, and its solution, is more specifically an example of the GoF Adapter
pattern.
Name: Adopter
Problem: How to resolve incompatible interfaces, or provide a stable interface to
similar components with different interfaces?
Solution: Convert the original interface of a component into another interface,
through an intermediate adapter object.

For example:
A solution is to add a level of indirection with objects that adapt the varying external interfaces
to a consistent interface used within the application. The solution is illustrated in Figure

14
Prepared By: RC
Factory
A common alternative in this case is to apply the Factory (or Concrete Factory) pattern, in
which a Pure Fabrication "factory" object is defined to create objects.
Factory objects have several advantages:
 Separate the responsibility of complex creation into cohesive helper objects.
 Hide potentially complex creation logic.
 Allow introduction of performance-enhancing memory management strategies, such as
object caching or recycling.

Name: Factory
Problem: Who should be responsible for creating objects when there are special
considerations, such as complex creation logic, a desire to separate the
creation responsibilities for better cohesion, and so forth?
Solution: Create a Pure Fabrication object called a Factory that handles the
creation.

A Factory solution is illustrated in figure below

15
Prepared By: RC
Singleton

Name: Singleton
Problem: Exactly one instance of a class is allowed—it is a "singleton." Objects
need a global and single point of access.
Solution: Define a static method of the class that returns the singleton.

For example, Figure below shows an implementation of the Singleton pattern.

16
Prepared By: RC
Observer/Publish-Subscribe/Delegation Event Model

An example is described in figure below.

17
Prepared By: RC
Fig: Observer pattern

18
Prepared By: RC