Grasp

General Responsibility Assigment Software Patterns or Prinsibles

1. GRASP
General Responsibility Assigment Software Patterns or Prinsibles
Cem BASARANOGLU
[email protected]

2. Background
●In 1987, Kent Beck and Ward Cunningham launched Design Patterns as a concept.These concept
based on Christopher Alexander’s applications architecture.
●In 1993, Gang of Four ( Eric Gamma, John Vlissides, Ralph Johnson,Richard Helm) started to
working on conceptual design patterns.
●In a little while, They created 23 patterns.
●In 1994, They published Design Patterns: Elements of Reusable Object-Oriented Software
(October 21)
●In 1997, Craig Larman wrote a book which name is Applying UML and Patterns : An introduction to
Object Oriented Analysis and Design 1st Edition

Cem BASARANOGLU
[email protected]

3. Concept - Grasp,Why?
We use the objects without exception in all applications we have developed.For this reason the objects
are of great importance to us.And we know that ,the objects are really indispensable for us.So,
●What kind of problems do we have when designing,defining or creating the objects?
●Do we foresee what kind of problems that these objects will cause?
●Do we care about any rules or qualification when designing or creating objects?
In my opinion, we do not consider about the next step when we design, define or create.Unfortunately,
our ignorance leads to bigger design or system problems later on.

Cem BASARANOGLU
[email protected]

4. Concept - Grasp,Why? (Continues)
Graps created by Craig Larman to encompass nine object‐oriented design principles related to creating
responsibilities for classes.Also, it is an acronym for these principles.
Larman defining Graps as : “understand essential object design and apply reasoning in a methodical,
rational, explainable way.”
Graps used to assign responsibility to our objects.So,It is all about assigning and defining objects and it’s a
collection of object design pattern.

Cem BASARANOGLU
[email protected]

5. Concept - Grasp,Why? (Continues)


●Understand the problem that you're facing in your specific design, and
●Use the GRASP guidelines for imagining and designing a robust solution.
Cem BASARANOGLU
[email protected]

6. What does ‘Object Responsibility’ Mean?
Responsibilities are related to the obligations of an object in terms of its behavior and Responsibilities
are assigned to classes of objects during object design.
And we have two types of responsibility for an object.
●Doing
●Knowing

Cem BASARANOGLU
[email protected]

7. Doing Responsibilities
Our objects are designed with the aim of being used in certain tasks.Each object is obliged to perform one
or more tasks.For example;
●An object can create another object.
●An object initiating another object.
●An object controlling and coordinating activities in other objects

Cem BASARANOGLU
[email protected]

8. Knowing Responsibilities
It covers the information that the object possesses about itself or other objects.For example;
●Knowing about Private encapsulated data
●Knowing about related objects
●Knowing about things it can derive or calculate
Cem BASARANOGLU
[email protected]

9. Design Patterns vs GRASP
I believe, this comparison will not be a fair.Because, Grasp only about the objects.On the other
hand,Design Patterns is a named description of a problem and a corresponding reusable solution.
Cem BASARANOGLU
[email protected]

10. Principles
●Creator
●Information Expert
●Controller
●Low Coupling
●High Cohesion
●Polymorphism
●Pure Fabrication
●Indirection
●Protected Variations
Cem BASARANOGLU
[email protected]

11. Demonstration
Use Monopoly board game example, domain model as shown below.
Cem BASARANOGLU
[email protected]

12. Principles - Creator
Problem : Who should be responsible for creating a new instance of other class?(Suppose you have two
classes A and B) Assigned well, the design can support low coupling, increased clarity, encapsulation, and
reusability. If done poorly, this choice can affect coupling, clarity, encapsulation, and reusability.
Solution : Assign class B the responsibility to create an instance of class A if one of the below is true (the
more the better).If more than one option applies, usually prefer a class B which aggregates or contains A.
●B contains or is composed of 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.
Cem BASARANOGLU
[email protected]

13. Principles - Creator(Approach)

●Closely look at domain/ design model and ask: who should be creating these classes?
●Search for the classes who create.
●Assign the responsibility of creation.
Cem BASARANOGLU
[email protected]

14. Principles - Creator(Example)

In Monopoly, which class should create the board square objects? From the domain model, the Board
object contains Square objects, so it is a good candidate.
Cem BASARANOGLU
[email protected]

15. Principles - Creator(Implementation)


Cem BASARANOGLU
[email protected]

16. Principles - Creator(Benefits & Liabilities)



Benefits
●Supports low coupling.
●Responsibility assigned to a class which fulfills the criteria, separating the logic for creation and
actual execution.
Liabilities
Sometimes creation may require significant complexity. Many times there is tight coupling between the
creator and created class. Also the task of destroying the objects might need to be taken into account.
Pooling such instances becomes important for the performance reasons.

Cem BASARANOGLU
[email protected]

17. Principles - 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

Cem BASARANOGLU
[email protected]

18. Principles - Information Expert(Approach)


●State the responsibility clearly.
●Search for the classes who have the information needed to fulfill the responsibility.
●Assign the responsibility.
Cem BASARANOGLU
[email protected]

19. Principles - Information Expert(Example)



Different objects need to be able to reference a particular square. For example, the player's Piece needs
to find the square to it will be moved to and the options pertaining to that square. The Board aggregates
all of the Squares, so the Board has the information needed to fulfill this responsibility.

Cem BASARANOGLU
[email protected]

20. Principles - Information Expert (Benefits &
Liabilities)





Benefits
●Encapsulation is maintained as objects use their own data to fulfill the task.
●Supports low coupling.
●Behaviour (responsibility) is distributed across the classes that have the required information
encourages highly cohesive, lightweight classes.
Liabilities
Sometimes while assigning responsibilities, lower level responsibilities are uncovered.

Cem BASARANOGLU
[email protected]

21. Principles - Controller


Problem : Who should be responsible for handling a system event?
Solution : Assign the responsibility for handling a system event message to a class representing one of
the following:
●A class that represents the overall system, device, or sub-system (façade controller).
●A class that represents a use case within which the system event occurs (a session controller or use
case controller).
●Represents the overall business (façade controller).
●Represents something in real world that is active (role controller).


Cem BASARANOGLU
[email protected]

22. Principles - Controller(Approach)



●Closely look at domain/design model to find when you have family of classes doing work/job
pertaining to some specific function and would need some facilitator
●Add a new class to take the responsibility of controller or manager, where all client code would
access the functionality through this class.
Cem BASARANOGLU
[email protected]

23. Principles - Controller(Example)
Since the first system message would be "Play Game" from the human player opening the game, the
MonopolyGame class is a suitable object to be the controller.
Cem BASARANOGLU
[email protected]

24. Principles - Controller(Benefits & Liabilities)


Benefits
●Supports low coupling.
●Promotes understandability and maintainability.
Liabilities
Sometimes grouping of responsibilities or code into one class or component to simplify maintenance
occurs when controllers are designed.should be avoided to prevent bloated controllers.
Bloated Controller: controllers which handle too many system events leading to low cohesion. This can be avoided by addition of a few more controllers.
Cem BASARANOGLU
[email protected]

25. Principles - Low Coupling



Problem : How to support low dependency, low change impact, and increased reuse?
Solution : Assign a responsibility so that coupling remains low. Use this principle to evaluate alternatives.
Coupling refers to any type of tangible dependency between elements ; classes, subsystems, systems, etc.
and is referenced by its degree:
● Weak (low) is good.
● Strong (high) is bad.



Cem BASARANOGLU
[email protected]

26. Principles - Low Coupling(Approach)




●Closely look for classes with many associations to other classes.
●Look for the methods that rely on a lot of other methods (or methods in other classes i.e.
dependencies).
●Rework the design so as to assign responsibilities to different classes in such a way that they have
lesser
Cem BASARANOGLU
[email protected]

27. Principles - Low Coupling(Examples)





In our current design, the Board object is the only object that gets the Square object. If we had instead
designed it so that each player's piece had a method to get a new Square each move, we would have a
poor design with high (bad) coupling.

28. Principles - Low Coupling(Benefits &
Liabilities)






Benefits
●Little or no affect on the module by changes in other components improved maintainability.
●Easy to understand.
●Convenient to reuse and easier to grab hold of classes improved reusability.
Liabilities
Attemping to remove all coupling can result in intense over-work and is unrealistic.



Cem BASARANOGLU
[email protected]

29. Principles - High Cohesion




Problem : How to keep objects focused, understandable, and manageable, and as a side effect, support
Low Coupling?
Solution : Cohesion refers to the functional cohesion between elements (classes, subsystems, systems,
etc.), which is a measure of how strongly focused the responsibilities of an element are.




Cem BASARANOGLU
[email protected]

30. Principles - High Cohesion (Approach)





●Closely look for classes with too many or too disconnected methods.
●Look for the methods which do a lot (look for method names having words like “AND”, “OR”).
● Assign a responsibility in such a way that all the responsibilities in a class are related.
Cem BASARANOGLU
[email protected]

31. Principles - High Cohesion (Examples)






Assume that the MonopolyGame class is the controller:
●If MonopolyGame performs most of the game functions within the software object ;low cohesion.
●If the functions are delgated to other software objects ;high cohesion.
Cem BASARANOGLU
[email protected]

32. Principles - High Cohesion (Benefits &
Liabilities)







Benefits
●Clarity and ease of understanding design is increased.
●Maintenance and enhancements are simplified.
●Low coupling is often supported.
●Small size classes with highly related functionality increases reuse.
Liabilities
In scenario of server objects: desirable to have less cohesive server objects due to performance needs
(performance matters more than anything else) ↠ instead of having many different highly cohesive
interfaces/components, use a single interface with many unrelated operations.




Cem BASARANOGLU
[email protected]

33. Principles - Polymorphism





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 responsibilities for the
behavior using polymorphic operations to the types for which the behavior varies
●Polymorphic operations are those that operate on differing classes
●Don’t test for the type of the object and use conditional logic to perform varying statements based
on type.




Cem BASARANOGLU
[email protected]

34. Principles - Polymorphism (Approach)






●Identify classes/ types which would have the behaviour changing slightly.
●Look for the methods which use conditional statements.
●Assign a responsibility to a type for which the behaviour varies.
Cem BASARANOGLU
[email protected]

35. Principles - Polymorphism (Example)







In Monopoly, there are different types of actions that can occur depending on the type of square a player
lands on abstract the Square object and its landedOn method, implementing different Square types with
their unique landedOn method, as shown below:
Cem BASARANOGLU
[email protected]

36. Principles - Polymorphism (Benefits &
Liabilities)








Benefits
●Unknown extensions required for new variants are easy to add.
●Maintenance and enhancements are simplified.
Liabilities
Code that is initially simple may become unnecessarily complex.





Cem BASARANOGLU
[email protected]

37. Principles - Pure Fabrication






Problem : What object should have the responsibility, when you do not want to violate High Cohesion
and Low Coupling, or other goals, but solutions offered by Expert (for example) are not appropriate?
Solution : Assign a highly cohesive set of responsibilities to an artificial or convenience class that does not
represent a problem domain concept—something made up, to support high cohesion, low coupling, and
reuse





Cem BASARANOGLU
[email protected]

38. Principles - Pure Fabrication (Approach)







Closely look at domain/ design model and locate the classes with low cohesion and high coupling. Create
a new class to take the responsibility of functionality causing low cohesion and high coupling.
Cem BASARANOGLU
[email protected]

39. Principles - Pure Fabrication (Example)








●Dice are used in many games.
●Putting the rolling/summing responsibilities in Player makes it impossible to generalize dice.
●Also makes it difficult to ask for the current dice total without rolling again.
●Use Cup to hold the dice, roll them, know their total dice can be reused in many different
applications.
Cem BASARANOGLU
[email protected]

40. Principles - Pure Fabrication (Benefits &
Liabilities)









Benefits
●Supports low coupling.
●Results in high cohesion.
●Promotes resuability.
Liabilities
Sometimes such design may result into bunch of classes having a single method which is a kind of overkill.






Cem BASARANOGLU
[email protected]

41. Principles - Indirection







Problem : Where to assign a responsibility, to avoid direct coupling between two (or more) things? How
to decouple 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.
● The intermediary creates the indirection

Cem BASARANOGLU
[email protected]

42. Principles - Indirection (Approach)








Closely look at domain/ design model and locate the classes with low coupling or direct coupling. Use an
existing class to take the responsibility of functionality causing low coupling and also the functionality
has high potential for reuse.
Cem BASARANOGLU
[email protected]

43. Principles - Indirection (Example)









From the previous example of using a Cup object instead of using Dice: this creates an intermediate
object (between Player and Dice) that reduces the coupling between Player and Dice, and that also
allows Dice to remain reusable for other games.
Cem BASARANOGLU
[email protected]

44. Principles - Indirection (Benefits & Liabilities)










Benefits
●Supports Low Coupling.
●Results in high reusability.
Liabilities
Sometimes such design may result into bunch of classes having a single method which is a kind of overkill.







Cem BASARANOGLU
[email protected]

45. Principles - Protected Variations








Problem : How to design elements (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


Cem BASARANOGLU
[email protected]

46. Principles - Protected Variations (Approach)









●Closely look for elements with direct coupling and also relatively prone to change.
●Identify for the objects or points of predicted variation.
●Assign these responsibilities in such a way to create a stable interface around them.
Cem BASARANOGLU
[email protected]

47. Principles - Protected Variations (Example)










By abstracting the Piece object, future Pieces may be added depending on the game theme.
Cem BASARANOGLU
[email protected]

48. Principles - Protected Variations (Benefits &
Liabilities)












Benefits
●Extensions required for new variations are easy to add.
●New implementations can be introduced without affecting clients.
●Coupling is lowered.
●The impact or cost of changes can be lowered.
Liabilities
The design cost of speculative “future-proofing” (protecting from future variations) may outweigh the
design cost incurred by a simple design that is reworked as necessary. Sometimes a simple design with no
PV can cost a lot less in the current time and this can be reworked when future variation becomes reality.








Cem BASARANOGLU
[email protected]

49. Sources
Larman, Craig, Applying UML and patterns : an introduction to object-oriented analysis and design and
iterative development
Cem BASARANOGLU
[email protected]