GoF Sections Design Problems and Design Patterns

Warning – Reading this Book May Cause an Uncontrollable Urge to Redesign Everything Don’t 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 isn’t right

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

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

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 aren’t 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

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)

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)

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

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)

Selecting a Design Pattern Additional Approaches  Beg, borrow or steal ideas from other people  Do it wrong, then fix it

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