Notes on Chapter 1 of Patterns
Home Page For Text
http://hillside.net/patterns/
What Is a Design Pattern?
Four Essentials
- Pattern Name - Provides a method to communicate about design and formalizes
an idea thus allowing user to say "I've seen this before."
- Problem - When do you apply this pattern.
- Solution - An abstract description of problem design that can be used on many
problems.
- Consequences - Costs and benefits of applying a pattern.
Organizing the Catalog
All of the patterns are grouped using two criteria. The first is purpose. All of the patterns
are divided into three main purposes.
- Creation patterns used to create classes or objects of from a collection of objects.
- Structural patterns deal with the composition of classes and objects
- Behavioral patterns deal with ways in which objects or classes interact and
distribute responsibility.
A second way to classify patterns is their scope. This classsification is
based on whether a pattern applies to classes or objects.
How Design Patterns Solve Design Problems
Finding Appropriate Objects
Hard part of ood is decomposition of a system into objects. The following factors
influence decompostion, often in conflicting ways.
- encapsulation
- granularity - size and number of objects in a class
- dependency
- flexibility
- performance
- evolution
- reusability
Some of the classes are based on concrete (real-world) objects while others
are problem solving artifacts such as structures (arrays etc.) and abstract base
classes.
Putting Reuse Mechanisms to Work
Inheritance (is-a) versus Composition (has-a) is a topic we have discussed and will
continue to discuss. Some important points of the section:
Weaknesses of Inheritence
- Inheritence breaks encapsulation since children often have to work with parents internal values.
- Can't change the implementations inherited from a parent at run-time because inheritence relations
are defined at compile-time.
- You may inherit functions that are not appropriate in the new class.
Addvantages of Composition
- Object composition is defined dynamically at runt-time through objects acquiring refernces to other objects.
- Composed objects don't violate encapsulation.
- Fewer interface dependencies.
- Class hierarchies remain small.
How to Select a Design Pattern
With more than 20 design patterns in the catalog to choose from, it might be hard to find the one that
addresses a particular design problem, especially if the catalog is new and unfamiliar to you. Here are several
different approaches to finding the design pattern that's right for your problem:
- Consider how design patterns solve design problems. Section 1.6 discusses how design patterns
help you find appropriate objects, determine object granularity, specify object interfaces, and several
other ways in which design patterns solve design problems. Referring to these discussions can help
guide your search for the right pattern.
- Scan Intent sections. Section 1.4 (page 8) lists the Intent sections from all the patterns in the catalog.
Read through each pattern's intent to find one or more that sound relevant to your problem. You can
use the classification scheme presented in Table 1.1 (page 10) to narrow your search.
- Study how patterns interrelate. Figure 1.1 (page 12) shows relationships between design patterns
graphically. Studying these relationships can help direct you to the right pattern or group of patterns.
- Study patterns of like purpose. The catalog (page 79) has three chapters, one for creational patterns,
another for structural patterns, and a third for behavioral patterns. Each chapter starts off with
introductory comments on the patterns and concludes with a section that compares and contrasts them.
These sections give you insight into the similarities and differences between patterns of like purpose.
- Examine a cause of redesign. Look at the causes of redesign starting on page 24 to see if your
problem involves one or more of them. Then look at the patterns that help you avoid the causes of
redesign.
- Consider what should be variable in your design. This approach is the opposite of focusing on the
causes of redesign. Instead of considering what might force a change to a design, consider what you
want to be able to change without redesign. The focus here is on encapsulating the concept that
varies, a theme of many design patterns. Table 1.2 lists the design aspect(s) that design patterns let you
vary independently, thereby letting you change them without redesign.
How to Use a Design Pattern
Once you've picked a design pattern, how do you use it? Here's a step-by-step approach to applying a
design pattern effectively:
- Read the pattern once through for an overview. Pay particular attention to the Applicability and
Consequences sections to ensure the pattern is right for your problem.
- Go back and study the Structure, Participants, and Collaborations sections. Make sure you
understand the classes and objects in the pattern and how they relate to one another.
- Look at the Sample Code section to see a concrete example of the pattern in code. Studying the
code helps you learn how to implement the pattern.
- Choose names for pattern participants that are meaningful in the application context. The names
for participants in design patterns are usually too abstract to appear directly in an application.
Nevertheless, it's useful to incorporate the participant name into the name that appears in the
application. That helps make the pattern more explicit in the implementation. For example, if you use
the Strategy pattern for a text compositing algorithm, then you might have classes
SimpleLayoutStrategy or TeXLayoutStrategy.
- Define the classes. Declare their interfaces, establish their inheritance relationships, and define the
instance variables that represent data and object references. Identify existing classes in your application
that the pattern will affect, and modify them accordingly.
- Define application-specific names for operations in the pattern. Here again, the names generally
depend on the application. Use the responsibilities and collaborations associated with each operation as
a guide. Also, be consistent in your naming conventions. For example, you might use the "Create-"
prefix consistently to denote a factory method.
- Implement the operations to carry out the responsibilities and collaborations in the pattern. The
Implementation section offers hints to guide you in the implementation. The examples in the Sample
Code section can help as well.
These are just guidelines to get you started. Over time you'll develop your own way of working with design
patterns.