CSSE374 Elaboration GRASP Intro to Patterns

1
Right Cover of the classic Gang of Four design
patterns book.
CSSE374 Elaboration GRASP! Intro to Patterns
Steve Chenoweth Day 9, Dec 15, 2008
2
Today

• Project How are the domain models going?
• Tues 6 AM!
• Then well discuss in class feedback from cust
• Review MVC The Video http//www.railsenvy.co
  m/tags/MVC
• Discussion - Continue Elaboration (Design)
• Fridays slide set (deferred to today)
• UML Interaction Diagrams Ch 15
• UML Class Diagrams Ch 16
• Todays (the following slides)
• GRASP An intro to OO patterns Ch 17
• Tomorrow Well use some of the time to catch
  up, if needed
• Discuss the GRASP patterns in more detail

3
What to do after req domain modeling?

• Basically, at this point you now have
• A domain model other req first pass
• You can detail any of this as a part of design
• You can strategize the big picture of what youve
  got
• Ideas about packaging things for systems (Ch 13)
• Some incentive to draw a bit before coding (Ch
  14)
• Knowledge of how to do class diagrams (Ch 16)
  related dynamic models (Ch 15)
• Well look at GRASP as a next strategy

Ch 17
4
Main ideas

• Add to the domain model
• Focus on the particular areas of the application
• Methods to the appropriate classes
• Messaging between the objects
• How to fulfill the req
• Focus on design principles and the domain
• Know how tos like UML so you dont have to
  focus on them

5
Key methods to use

• Test-first
• Start coding right away
• Design at the same time visual modeling
• Use
• GRASP p. 277
• Gang of Four (GoF) patterns p. 435
• Responsibility-driven design p. 276
• In modeling, go for needed outputs
• UML for difficult parts of the system
• UI sketches prototypes
• Database models
• Report sketches prototypes

6
Fig 17.1
7
Responsibility-Driven Design (RDD)

• Think of software objects as having
  responsibilities a contract or obligation to
  perform a certain role. Things like
• Create another object
• Do a calculation
• Initiate action in other objects
• Controlling and coordinating activities in other
  objects
• Doing such things also requires that the object
  know things, like
• Its own encapsulated data
• Related objects
• What it can derive or calculate
• A responsibility isnt the same as a method, but
  can be some span classes

8
RDD is a metaphor

• Think of your classes as a community people with
  responsibilities and collaborations
• A community of collaborating, responsible objects
• As you develop these, usually youre doing the
  same thing with colleagues!

Right Success thru collaboration, from
www.cocreate.org.uk/ .
9
GRASP is a learning aid for RDD

• Based on patterns of assigning responsibilities
• Helps you GRASP the fundamentals
• Think about assigning responsibilities, while
  coding or designing
• Fits with drawing interaction diagrams

Fig 17.2 Responsibilities and methods are
related.
10
What are Patterns?

• Principles and idioms, codified in a structured
  way, describing a problem and its solution.
• Sample
• 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 fill it.

11
OO Patterns

• In OO design, a pattern is a named description of
  a pattern and solution that can be applied in new
  contexts.
• A good pattern is a named and well-known
  problem/solution pair, with advice on how to
  apply it in novel situations and discussion of
  its trade-offs, implementation, variations, etc.
• Great patterns codify tried-and-true knowledge.
• A goal of this class learn to use well-known
  patterns, like the GRASP and GoF patterns.

12
So, what is GRASP, anyway?

• 9 basic OO design principles.
• We use the common pattern style to describe them.
• Could also call them principles.
• So, GRASP General Responsibility Assignment
  Software Patterns or Principles.
• They are described on inside front cover of the
  book.

13
What are the 9 GRASP Patterns?

• Information Expert
• Creator
• Controller
• Low Coupling (evaluative)
• High Cohesion (evaluative)
• Polymorphism
• Pure Fabrication
• Indirection
• Protected Variations

? ? ?
These first 5 are covered in Ch 17.
14
GRASP Example - Monopoly

• Design problem Who creates the Square object?

Fig 9.28 17.3 Monopoly partial domain model.
Monopoly board from www.codinghorror.com/blog/arch
ives/000628.html .
15
Larmans modest proposal

• Have a Dog object create a Square.
• Whats wrong with that?

16
The experienced answer

• Dog doesnt support having a low
  representational gap (LRG) between how we think
  of the domain and a straightforward
  correspondence with software objects.
• What choice would have an LRG here?

17
Board creates Square Why?

• Intuitively, containers create the things
  contained.
• Uses the Creator pattern
• Name Creator
• Problem Who creates an A?
• Solution Assign class B the responsibility to
  create an instance of the 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.

18
GRASP patterns Note that

• A and B are software objects, not domain model
  objects.
• First look at existing software objects, before
  inventing new ones.
• If you need to create new ones, then look at the
  domain model.
• Try for parallel, complementary dynamic and
  static object models ?

19
Thus
So, this domain model
Suggests this start on the object model.
20
Monopoly Next design problem

• Who knows about a Square object, given a key?
• E.g., need to be able to ref a particular Square,
  given its name, like Park Place.
• This is a Knowing responsibility. (slide 7 p.
  276)
• Use the Information Expert (slide 10) to decide
  who should be responsible for this knowledge.
• Which object would you choose?

21
Board again why?

• Why Board over Dog?
• Because Board knows about all the squares
  already.
• Using it as the ongoing source of this info gives
  low coupling
• Coupling measures how strongly one element is
  connect to, has knowledge of, or depends on other
  elements.
• What all can be affected when something else
  changes?

22
Low coupling

• A cardinal goal in building software.
• Information Expert relies on it.
• 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.

23
Fig 17.6 Board knows Squares.
This is a DCD the other UML interaction
diagram style.
Fig 17.7 Dog knows Squares.
24
Monopoly Next design problem

• What should happen when the user clicks the
  JButton (say) called Play Game?

25
Something should convert the meaning!

• JButton click ? Play Game intent.
• The MVC Controller does this. Its pattern
• 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 (these are all variations of a
  façade controller).
• Represents a use case scenario within which the
  system operation occurs (a use case or session
  controller).

Which of these choices would you make for Play
Game?
26
Monopoly Last design problem

• What to do after starting the game?
• How should we design the rest?

Fig 17.11
27
Why is small classes better?

• High cohesion easy to identify the relatedness
  of the code.
• The pattern
• 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
The rest of Ch 17

• Elaborates on each of the first 5 of these 9
  GRASP patterns.
• Shows each of them in a full pattern format
• Name
• Problem
• Solution
• Example
• Discussion
• Contraindications
• Benefits
• Related Patterns or Principles

Study these examples well discuss some on
Thursday E.g., the MVC example on pp 309-311.