GoF Sections 1.6-1.8

1
GoF Sections 1.6-1.8

• Design Problems and Design Patterns

2
Warning Reading this Book May Cause an
Uncontrollable Urge to Redesign Everything

• Dont Read this Book Too Close to a Deadline!
• Decision Related Stress
• Results from having to decide whether to
• Explain to your boss why you redesigned the
  project a week before the ship date
• or
• Finish a design you know isnt right

3
How Design Patterns Solve Design Problems

• Find Appropriate Objects
• Patterns bring a set of objects with them,
  helping ensure low-level objects and high-level
  abstractions are not overlooked
• Determine Object Granularity
• Patterns determine object granularity by
  specifying what types of objects are required for
  implementing the pattern
• Specify Object Interfaces
• Patterns describe what interfaces need to be
  supported and what kinds of data needs to be
  handled
• Patterns describe relationships between
  interfaces and place requirements/constraints on
  classes and even other patterns

4
How Design Patterns Solve Design Problems

• Specify Object Implementations
• Patterns give a blueprint for implementation by
  defining such things as class relationships
  (class diagrams), abstract vs. concrete classes
  and class vs. interface inheritance
• Put Reuse Mechanisms to Work
• Pattern definitions specify which reuse
  techniques (inheritance, composition,
  parameterized types) apply to the pattern

5
How Design Patterns Solve Design Problems

• Relate Run-Time and Compile-Time Structures
• Patterns capture the distinction between run-time
  and compile-time structures that arent always
  clear when looking at code and data structures
• Design for Change
• Patterns anticipate change in certain areas of
  the system, thus incorporating flexibility to
  account for future changes without redesigning
  the system
• The flexibility incorporated by patterns tends to
  generate reusable designs

6
Patterns and Reuse

• Patterns can make reuse easier in in a variety of
  systems with different reuse needs
• Applications (internal reuse)
• Toolkits (code reuse)
• Frameworks (design reuse)

7
Causes of Redesign and Solutions Using Patterns

• Explicit Class Specification
• Avoid committing to a particular implementation
  by creating objects indirectly
• Dependence on Specific Operations
• Provide multiple ways for satisfying requests
• Platform Dependence
• Eliminate platform dependencies by separating
  abstractions from implementations
• Implementation/Representation Dependence
• Prevent changes from cascading thorough a design
  by hiding implementations and representations
  from clients (program to an interface, not an
  implementation)

8
Causes of Redesign and Solutions Using Patterns

• Algorithmic Dependencies
• Decouple algorithms from objects by isolating
  algorithms and allowing it to be replaced
  independently
• Tight Coupling
• Eliminate coupling between classes to allow each
  class to be used (or reused) independently
• Subclassing
• Provide alternatives to subclassing, which can be
  expensive (during implementation as well as at
  run-time)
• Inflexible Classes and Hierarchies
• Provide ways of modifying classes when
  manipulation of the source code is problematic

9
Selecting a Design Pattern

• Six Approaches Noted by the Author
• Consider how patterns solve design problems
  (section 1.6)
• Scan Intent sections (section 1.4)
• Study pattern interrelationships (figure 1.1)
• Study patterns categorically (table 1.1)
• Examine causes of redesign (pp 24,25)
• Consider what needs to change (table 1.2)

10
Selecting a Design Pattern

• Additional Approaches
• Beg, borrow or steal ideas from other people
• Do it wrong, then fix it

11
Using a Design Pattern

• Seven Step Approach to Applying Patterns
• Read the pattern to get an overview
• Study the Structure, Participants and
  Collaborations sections
• Study the sample code
• Rename the participants to match the context
• Define the classes
• Create context-specific names for pattern
  operations
• Implement the pattern operations
• Consider How Not to Apply Patterns
• Need to consider consequences patterns are one
  tool in the toolbox, not a panacea