Chapter 6: GRASP: Designing Objects with Responsibilities

1

• Chapter 6 GRASP Designing Objects with
  Responsibilities

2

• Objective
• Learn to apply five of the GRASP principles or
  patterns for OOD.

3
6.1. UML versus Design Principles

• The critical design tool for software development
  is a mind well educated in design principles.
• not the UML or any other technology.

4
6.2. Object Design Example Inputs, Activities,
and Outputs

• What Are Inputs to Object Design?
• What Are Activities of Object Design?

5
6.2. Object Design Example Inputs, Activities,
and Outputs

• What Are the Outputs?
• UML interaction, class, and package diagrams
• UI sketches and prototypes
• database models
• report sketches and prototypes

6
6.3. Responsibilities and Responsibility-Driven
Design

• A way of thinking about the design of software
  objects
• Responsibilities
• Roles
• Collaborations

7
6.3. Responsibilities and Responsibility-Driven
Design

• Two kinds of responsibilities
• Doing responsibilities
• doing something itself
• initiating action in other objects
• controlling and coordinating activities in other
  objects
• Knowing responsibilities
• knowing about private encapsulated data
• knowing about related objects
• knowing about things it can derive or calculate

8
6.4. GRASP A Methodical Approach to Basic OO
Design

• General Responsibility Assignment Software
  Patterns ( GRSAP )
• a methodical, rational, explainable way to
  understand object design and apply design
  reasoning
• based on patterns of assigning responsibilities

9
6.5. What's the Connection Between
Responsibilities, GRASP, and UML Diagrams?
10
6.6. What are Patterns?

• Named description of a problem and solution that
  can be applied to new contexts

Pattern Name Information Expert ProblemWhat is
a basic principle by which to assign
responsibilities to objects? SolutionAssign a
responsibility to the class that has the
information needed to fulfill it.
11
6.6. What are Patterns?

• 'New Pattern' is an Oxymoron
• The Gang-of-Four Design Patterns Book

12
6.7. Where are We Now?

• The iterative process background
• Prior artifacts?
• How do they relate to OO design models?
• How much time should we spend design modeling?
• RDD as a metaphor for object design
• a community of collaborating responsible objects.
• Patterns as a way to name and explain OO design
  ideas
• Patterns can be applied during modeling and
  during coding.
• GRASP for basic patterns of assigning
  responsibilities,
• GoF for more advanced design ideas.
• UML for OO design visual modeling,
• both GRASP and GoF patterns can be applied

13
6.8. A Short Example of Object Design with GRASP

• Nine GRASP patterns
• Creator
• Information Expert
• Low Coupling
• Controller
• High Cohesion

14
6.8. A Short Example of Object Design with GRASP

• Creator
• Problem Who creates the Square object?

• NameCreator
• ProblemWho creates an A?
• Solution Assign class B the responsibility to
  create an instance of class A if one of these is
  true (the more the better)
• B "contains" or compositely aggregates A.
• B records A.
• B closely uses A.
• B has the initializing data for A.

15
6.8. A Short Example of Object Design with GRASP
16
6.8. A Short Example of Object Design with GRASP
17
6.8. A Short Example of Object Design with GRASP

• Information Expert
• Problem Who knows about a Square object, given a
  key?

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.
18
6.8. A Short Example of Object Design with GRASP
19
6.8. A Short Example of Object Design with GRASP

• Low Coupling
• Question Why Board over Dog?

Name Low Coupling Problem How to reduce the
impact of change? Solution Assign
responsibilities so that (unnecessary) coupling
remains low. Use this principle to evaluate
alternatives.
20
6.8. A Short Example of Object Design with GRASP
21
6.8. A Short Example of Object Design with GRASP

• Controller

22
6.8. A Short Example of Object Design with GRASP
23
6.8. A Short Example of Object Design with GRASP

• Name Controller
• Problem What first object beyond the UI layer
  receives and coordinates ("controls") a system
  operation?
• Solution Assign the responsibility to an object
  representing one of these choices
• Represents the overall "system," a "root
  object," a device that the software is running
  within, or a major subsystem.
• Represents a use case scenario within which the
  system operation occurs

24
6.8. A Short Example of Object Design with GRASP

• Option 1 Represents the overall "system," or a
  "root object
• such as an object called MonopolyGame.
• Option 1 Represents a device that the software
  is running within
• Option 2 Represents the use case or session.
• a software class such as PlayMonopolyGameHandler.

25
6.8. A Short Example of Object Design with GRASP
26
6.8. A Short Example of Object Design with GRASP

• High Cohesion

27
6.8. A Short Example of Object Design with GRASP
Name High Cohesion Problem How to keep objects
focused, understandable, and manageable, and as a
side effect, support Low Coupling? Solution
Assign responsibilities so that cohesion remains
high. Use this to evaluate alternatives.
28
6.9. Applying GRASP to Object Design

• Nine GRASP Patterns

• Indirection
• Low Coupling
• Polymorphism
• Protected Variations

• Creator
• Controller
• Pure Fabrication
• Information Expert
• High Cohesion

29
6.10. Creator

• Problem
• Who should be responsible for creating a new
  instance of some class?
• Solution
• B is a creator of A objects if one of these is
  true (the more the better)
• B "contains" or compositely aggregates A.
• B records A.
• B closely uses A.
• B has the initializing data for A.

30
6.10. Creator

• Example

31
6.10. Creator
32
6.10. Creator

• Discussion
• Contraindications
• When creation requires significant complexity
• delegate creation to a helper class
• Concrete Factory or Abstract Factory
• Benefits
• Low coupling is supported

33
6.11. Information Expert (or Expert)

• Problem
• What is a general principle of assigning
  responsibilities to objects?
• Solution
• Assign a responsibility to the class that has the
  information necessary to fulfill the
  responsibility.

34
6.11. Information Expert (or Expert)

• Example
• Grand total of a sale.
• If there are relevant classes in the Design
  Model, look there first.
• Otherwise, look in the Domain Model, and attempt
  to use its representations to inspire the
  creation of corresponding design classes.

35
6.11. Information Expert (or Expert)
36
6.11. Information Expert (or Expert)
37
6.11. Information Expert (or Expert)
38
6.11. Information Expert (or Expert)

• Assigns 3 responsibilities to 3 design classes of
  objects

39
6.11. Information Expert (or Expert)

• Discussion
• frequently used in the assignment of
  responsibilities
• "animation" principle in object design
• Contraindications
• responsible for saving a Sale in a database?
• Benefits
• Information encapsulation and low coupling
• High cohesion

40
6.12. Low Coupling

• Problem
• How to support low dependency, low change impact,
  and increased reuse?
• A class with high coupling
• Forced local changes because of changes in
  related classes.
• Harder to understand in isolation.
• Harder to reuse.
• Solution
• Assign a responsibility so that coupling remains
  low.

41
6.12. Low Coupling

• Example

42
6.12. Low Coupling

• Discussion
• A principle to keep in mind during all design
  decisions
• Common forms of coupling from TypeX to TypeY
• TypeX has an attribute that refers to a TypeY
  instance, or TypeY itself.
• A TypeX object calls on services of a TypeY
  object.
• TypeX has a method that references an instance of
  TypeY, or TypeY itself, by any means.
• TypeX is a direct or indirect subclass of TypeY.
• TypeY is an interface, and TypeX implements that
  interface.

43
6.12. Low Coupling

• Low Coupling encourages you to
• Assign a responsibility so that its placement
  does not increase the coupling.
• Supports the design of classes that are more
  independent.
• Classes that are inherently generic in nature and
  with a high probability for reuse should have
  especially low coupling.

44
6.12. Low Coupling

• Contraindications
• High coupling to stable elements and to pervasive
  elements is seldom a problem.
• Pick Your Battles
• Focus on the points of realistic high instability
  or evolution.
• Benefits
• not affected by changes in other components
• simple to understand in isolation
• convenient to reuse

45
6.13. Controller

• 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 the following choices
• Represents the overall "system," a "root object,"
  a device that the software is running within, or
  a major subsystem.
• Represents a use case scenario within which the
  system event occurs.
• Use the same controller class for all system
  events in the same use case scenario.
• Informally, a session is an instance of a
  conversation with an actor. Sessions can be of
  any length but are often organized in terms of
  use cases.

46
6.13. Controller

• Example
• Some system operations of the NextGen POS
  application.

47
6.13. Controller
48
6.13. Controller
49
6.13. Controller
50
6.13. Controller

• Discussion
• Use the same controller class for all the system
  events of one use case
• Maintain information about the state of the use
  case.
• Facade Controller
• Use Case Controller

51
6.13. Controller

• Benefits
• Increased potential for reuse and pluggable
  interfaces
• Opportunity to reason about the state of the use
  case
• Implementation
• Implementation with Java Swing Rich Client UI
• Implementation with Java Struts Client Browser
  and WebUI

52
6.13. Controller

• Bloated Controllers
• Signs of bloating
• There is only a single controller class receiving
  all system events in the system, and there are
  many of them.
• The controller itself performs many of the tasks
  necessary to fulfill the system event.
• A controller has many attributes, and it
  maintains significant information about the
  system or domain.
• Cures for a bloated controller
• Add more controllers
• Design the controller so that it primarily
  delegates the fulfillment of each system
  operation responsibility to other objects.

53
6.13. Controller

• UI Layer Does Not Handle System Events

54
6.13. Controller
55
6.14. High Cohesion

• Problem
• How to keep objects focused, understandable, and
  manageable, and as a side effect, support Low
  Coupling?
• Solution
• Assign a responsibility so that cohesion remains
  high.

56
6.14. High Cohesion

• A class with low cohesion
• hard to comprehend
• hard to reuse
• hard to maintain
• delicate constantly affected by change

57
6.14. High Cohesion

• Example

58
6.14. High Cohesion
59
6.14. High Cohesion

• Discussion
• A principle to keep in mind during all design
  decisions
• some scenarios that illustrate varying degrees of
  functional cohesion
• 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 other
  classes to fulfill tasks.
• Moderate cohesion
• A class has lightweight and sole responsibilities
  in a few different areas that are logically
  related to the class concept but not to each
  other.

60
6.14. High Cohesion

• Cohesion and Coupling Yin and Yang
• Contraindications
• Grouping of responsibilities or code into one
  class or component to simplify maintenance by one
  person
• Distributed server objects

61
6.14. High Cohesion

• Benefits
• Clarity and ease of comprehension of the design
  is increased.
• Maintenance and enhancements are simplified.
• Low coupling is often supported.
• Reuse of fine-grained, highly related
  functionality is increased because a cohesive
  class can be used for a very specific purpose.

62

• Questions Answers