GRASP Patterns

Best Practices for Object-Oriented

Software Design
GRASP Patterns
 GRASP: Generalized Responsibility
Assignment Software Patterns
 GRASP patterns are really more accurately
described as best practices
 GRASP patterns outline best practices which can
be employed in any object-oriented design
 These best practices, if used properly, will lead
to maintainable, reusable, understandable, and
easy to develop software
GRASP Patterns
 GRASP patterns describe how to assign
responsibilities to classes
 Warning: Grasps tend to be vague
 Responsibilities is “a contract or obligation
of a classifier” (UML definition)
 Responsibilities can include behaviour, data
storage, object creation and more
 They often fall into two categories:
 Doing
 Knowing
1. Information Expert
 Assign a responsibility (such as behaviour)
to the information expert
 An information expert is the class that has (or
has direct access to) the information necessary
to fulfill the responsibility
 e.g. A responsibility such as handling a
deposit (i.e. increase balance) should be
assigned to the Account class
 This is because Account contains the account
balance as one of its attributes
1. Information Expert
 This GRASP has the effect of having a
class with high cohesion
 Cohesion – the degree to which the
information and responsibilities of a class
are related to each other
 Cohesion is improved since the
information needed for a
responsibility is closely related to the
responsibility itself
2. Creator
 Give a class A the responsibility of creating
instances of another class, B, if:
 A is an aggregate of B
 A is a container of B
 If no classes apply, then assign the
responsibility to a class C if:
 C records instances of B
 C closely uses B objects
 C has the initializing data for B
2. Creator
 Whenever one class has the responsibility
of creating instances of another class, the
two classes are coupled
 Coupling itself is not wrong, but we want to
eliminate certain types of coupling
 Coupling of classes is a measure of how
strongly a class is connected to another
class
 Whenever two classes are coupled, one class
becomes dependent upon the other to function
correctly
2. Creator
 The Creator GRASP ensures that
coupling due to object instantiation
only occurs on closely related classes
 An aggregate or container of a class is
already coupled with that class
 Thus, assigning the creation
responsibility to the container or
aggregate does not introduce more
coupling
2. Creator
 e.g. Consider an Invoice which has a
number of InvoiceItems on it
 When a new Invoice is created, we might
wish to add new items to it
 It makes sense that the Invoice itself
would create instances of InvoiceItem,
and subsequently add them to itself
 The effect is that no other classes should
need to know about InvoiceItems (at
least not for this responsibility)
3. Low Coupling
 Assign a responsibility so that coupling
remains low
 This is pretty vague, but it means that we try to
keep low the number of classes to which a class
is coupled
 Creator is a more specific case of Low Coupling,
related to instantiation
 A good rule of thumb is: If class A is
already coupled with class B, assign a
responsibility for B to the class A
 This is only if it is not appropriate to assign the
responsibility directly to A (otherwise, this would
be contrary to Information Expert)
3. Low Coupling
 The Low Coupling ‘pattern’ is definitely a
best practice
 It is a good idea to keep coupling low in a design
 The reasons why Low Coupling is important
should be obvious:
 With Low Coupling, changes to a class (A) affect
fewer classes (the classes coupled to A)
 Thus Low Coupling improves the maintainability
of a software system
 A low coupled class is also easy to understand,
since it is often simpler and more cohesive
3. Low Coupling
 e.g. Suppose the total price for an Invoice
needs to be calculated
 To achieve this, the costs must be totalled of all
InvoiceItem instances
 Recall that the Creator GRASP already
recommends that we create instances of
InvoiceItem within Invoice
 Thus, Invoice is already coupled with
InvoiceItem
 The responsibility of total price should be
assigned to Invoice, since coupling will not be
increased
4. High Cohesion
 Assign a responsibility so that
cohesion remains high
 Again, this is vague, but it simply means
that we should always try to maintain
class cohesion
 This is another GRASP that is really more
like a best practice, than a pattern
4. High Cohesion
 When about to assign a responsibility,
ask yourself the following question:
 Is this responsibility related to the
other responsibilities of this class?
 If not, there is likely a need to assign
the responsibility to another class
 This may prompt you to create a new
class if other responsibilities exist that
are similar/related to this one
4. High Cohesion
 e.g. Consider a class Order, which
stores data about an order that has
been placed in an online store
 Responsibility: Store the contents of an
Order to secondary storage
 Should this responsibility be added to
the Order class?
 Are order details and persistence
management related concepts?
 No!! They are not even close!
4. High Cohesion
 To preserve cohesion, Order should not be
given this responsibility
 So what class should persist order details?
 Several possibilities exist, but here is one:
 A matching class (e.g. OrderDAO) whose
responsibility is merely to persist Orders
 Likely OrderDAO will have some persistence
code reuse (from a superclass or some other
class or subsystem)
4. High Cohesion
 Cohesion is important because incohesive
classes are large and cumbersome
 Such classes are usually thousands of lines long
 These classes are difficult to understand and
maintain
 It is also highly unlikely that a class with so
many unrelated responsibilities will be useful in
any other context
 There is little chance of class reuse
4. High Cohesion
 By contrast, cohesive classes represent a
single abstraction and responsibilities
related to that abstraction
 Classes representing a single abstraction could
be reused in any context that requires modeling
that abstraction
 Class reuse is possible when highly cohesive
 Cohesive classes are easy to maintain
 How do you find a bug related to storing order
details to the database? OrderDAO
 Cohesive classes are more modular, and
thus support teamwork
Cohesion and Coupling
 Cohesion and Coupling are two of the most
important concepts in software design
 However, they are not completely
unrelated:
 Highly coupled classes often are not cohesive
 A class that has been assigned many
responsibilities for many external classes is
unlikely to represent a single abstraction
5. Controller
 Assign the responsibility for receiving and
handling a system event message to a class
that is either:
 Representative of the entire subsystem (e.g. a
Façade Controller)
 Representative of the entire use case scenario
 Do not assign these responsibilities to View
classes (windows, dialogs, etc.)
 A Controller is never a user interface object
5. Controller
 This GRASP is just common sense:
 When a system event occurs, the class
who has the responsibility of performing
a high level function should receive
events indicating it should take place
 Often a subsystem will have one or more
Controller classes, each designed to
handle certain responsibilities
 Controller responsibilities are usually
extremely high-level
5. Controller
 e.g. In a bank system, we might have a
Controller that manages all banking
transactions (TransactionController)
 This class would have methods such as:
 deposit()
 withdraw()
 payBill()
 transfer()
 It makes sense that this class receive the event
generated when the teller clicks the ‘Execute Bill
Payment’ button on the user interface
5. Controller
 Some architectures stress the importance
of view/controller separation
 e.g. Some variations of the MVC, Layers
 For these architectures, the Controller
GRASP has to be slightly modified:
 One user interface might generate different
types of events than another UI
 To solve this problem, a View class can catch the
event, and generate a high-level event
corresponding to the requested behaviour
 The Controller would handle this event
5. Controller
 The GRASP mentioned that a Controller
that represents an entire subsystem might
be called a Façade Controller
 This is a variation of Façade, where the Façade
receives events (as well as method invocation
messages) and forwards them to the correct
subsystem component for handling
 This is essentially the same concept as the
Façade described earlier in the course
5. Controller
 Warning: Watch out for bloated Controllers
 This can happen if you have one Controller for the
entire system, for example
 Controllers can receive several events, but they
should delegate the responsibility of the
corresponding functionality to other classes
 e.g. The Façade Controller will receive the

event, and send a corresponding message to

the correct subsystem component to handle it
 One global Controller is usually a bad idea
 One common practice is to create a
Controller for each use case
5. Controller
 View classes generally should not receive
system events
 The reason for this is that when View classes
receive system events, they must call the
corresponding method in another class to handle
the behaviour
 This couples the View with this other class
 We’ve already discussed why coupling should
be avoided (especially between modules)
 Worse yet, the View class actually handling the
behaviour would definitely reduce cohesion
 The View class would have at least two
purposes: user interface and behaviour
Coupling
 Coupling cannot be avoided altogether
 Without coupling, all we could create would be
isolated and static classes
 Our software wouldn’t be able to do anything
 Reducing coupling should be one of the
factors taken into consideration when
assigning responsibilities
 Also, specific kinds of coupling should be
avoided:
 Coupling between two classes internal to two
different modules would be a big mistake as the
internal details of a module should be hidden
6. Polymorphism
 When related behaviours vary by type
(class), assign the responsibility
polymorphically to the specialization classes
 This is basically the purpose of polymorphism, so
it is natural for software developers to
understand
 This is not much of a pattern, and yet
another best practice
6. Polymorphism
 e.g. Consider a UML diagram drawing
program
 If shapes are responsible for drawing
themselves via the draw() method:
 Obviously, an Actor (stick figure) will draw itself
differently than a UseCase (ellipse)
 It might make sense in this case to have the
classes themselves handle the drawing by
polymorphically overriding the draw() method
 An advantage is that new entities (e.g. State)
can be easily added without changing the core
graphics code
6. Polymorphism
 Polymorphism can lead to highly cohesive objects
 Consider the example where some draw() method
were implemented similarly to this:
If (entity.type = “UseCase”) then
drawEllipse(…);
Else if (entity.type = “Class”) then
drawRectangle(…);
…
End if
 This is not highly cohesive, since it combines
unrelated behaviours, and it also strongly couples this
object with the shape it draws
7. Pure Fabrication
 To support high cohesion and low coupling,
where no appropriate class is present:
invent one
 Even if the class does not represent a problem
domain concept
 This is a compromise that often has to be
made to preserve cohesion and low
coupling
 Remember: the software is not designed to
simulate the domain, but operate in it
 The software does not always have to be
identical to the real world
7. Pure Fabrication
 Pure Fabrication is a compromise when
faced with a choice between modeling the
domain and preserving maintainability and
class reusability
 Software maintainability and reuse are always
more important in business, since they are ways
companies can preserve resources
 Usually, Pure Fabrication is used when
there is no appropriate class to use
 Usually, it is a good idea to try the other
patterns first to try to find a solution which more
closely resembles the domain entities
7. Pure Fabrication
 e.g. In the previous example is was
suggested that entities in a UML editor
draw themselves
 However, what if this is a difficult task?
 What if the drawing facilities vary depending on
what drawing facilities the user has installed?
 e.g. DirectX, OpenGL, etc.
 The real world suggests that the Architect
class draw the entities
 This is because architects draw UML diagrams
7. Pure Fabrication
 Architect might be used to store user
preferences, recently created diagrams and
projects, etc.
 This would obviously be a cohesion problem
 Pure Fabrication would suggest creating a
class whose job is to draw the entities
 One solution might be to have the Entity
instances associate with an instance of
EntityRenderer component
 There could be a subclass of EntityRenderer for
each subclass of Entity
 e.g. UseCaseRenderer, ActorRenderer
7. Pure Fabrication
 The difficulty then becomes: how do
we associate the entity instances with
the right instance of renderer?
 This is a problem easily solved by the
AbstractFactory pattern, discussed later
8. Indirection
 To avoid direct coupling between objects,
assign an intermediate object as a
mediator
1. Recall that coupling between two classes of
different subsystems can introduce maintenance
problems
2. Another possibility is that two classes would be
otherwise reusable (in other contexts) except
that one has to know of the other
 Coupling the two objects would reduce the
reuse contexts to where both abstract concepts
were relevant together
 The objects could not be reused separately
8. Indirection
 e.g. Consider an application for managing
group work
 Employee instances might need to be coupled to
Project instances
 However, potential for reuse of both Employee
and Project is high
 One solution is to assign a class
(Assignment) to couple the two classes
 In this case, the class represents an association
class (a class that represents an association)
8. Indirection
 The Façade pattern is another example of
Indirection
 The Façade prevents coupling classes in two
different subsystems
 Classes in one subsystem communicate
directly with the Façade
 The Façade communicates with the correct
subsystem component
 Thus, changes to the structure of the
subsystem will not affect the user of the
subsystem, thanks to the Façade
9. Protected Variations
 Assign responsibility to create a stable
interface around an unstable or predictably
variable subsystem or component
 If a component changes frequently, the users of
the component will also have to be modified
 This is especially time consuming if the
component has many users
 Wrapping the component in a stable
interface means that when variations occur,
the wrapper class need only be changed
 In other words, changes are localized
9. Protected Variations
 e.g. Big video game companies make
money by creating a 3D graphics game
engine (as well as sound, AI, etc.)
 These video game companies often produce
many games using the same engine, and release
the game on many consoles
 This is only possible to this extent using
Protected Variations
 If a game is to be ported to another console, the
wrapper object will have to delegate 3D graphics
drawing to different console-level commands
 However, the wrapper is simpler to change than
the entire game and all of its facets
9. Protected Variations
 These video game companies facilitate
additional revenue by making their wrapper
modules flexible, so that they can create
many games using the same interface
 Thus, a good practice is to leave out
unnecessary details in wrappers
 It is often useful to try to preserve the cohesion
(and thus reuse factor) of a subsystem by
keeping the interface flexible
 Obviously, the Façade pattern is also an
example of Protected Variations
9. Protected Variations
 One popular pattern using Protected
Variations is the Adapter
 An Adapter is another pattern, discussed later,
which adapts one interface for another
 Perhaps an application (e.g. a game) is written
to use a one interface (e.g. OpenGL for 3D
graphics)
 The application (game) might need to be
adapted to also run on other platforms (e.g.
DirectX/Direct3D)
 An Adapter is intended for this kind of
application
 An OpenGL-to-Direct3D adapter is possible
9. Protected Variations
 Among other examples are JDBC and ODBC:
 These are packages that allow applications to
access databases in a DB-independent way
 In spite of the fact that databases all use slightly
different methods of communication
 It is possible due to an implementation of
Protected Variations
 Users write code to use a generic interface
 An adapter converts the generic method calls to
DB-specific communications and vice versa
10. Don’t Talk to Strangers
 Do not couple two objects who have
no obvious need to communicate
 This is common sense: do not add
coupling where unnecessary
 Again, this is a best practice in
software
 Although common sense, this still must
be considered seriously, as a tendency
exists to model all possible relationships
10. Don’t Talk to Strangers
 Often the domain objects have
relationships that need not be modeled in
the application
 However, a common tendency is to model those
relationships (with aggregation, for instance)
anyway
 Model relationships only if they are
necessary to complete a use case
 Ultimately it is not relationships in the domain
that determine if relationships in software should
be present
10. Don’t Talk to Strangers
 e.g. Consider a convenience store
application
 Customers are people, as are Employees
 Should we model this as inheritance?
 In this application, customers are likely
anonymous
 Thus, Employee instances (which likely store
names and phone numbers) do not share any
common data or behaviour
 It makes sense that we not model this
relationship, despite our initial reactions