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 formalizesan 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 patternsare 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 anddistribute responsibility.
A second way to classify patterns is their scope. This classsification isbased 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 factorsinfluence 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 othersare problem solving artifacts such as structures (arrays etc.) and abstract baseclasses.
Putting Reuse Mechanisms to Work
Inheritance (is-a) versus Composition (has-a) is a topic we have discussed and willcontinue 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 relationsare 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 thataddresses a particular design problem, especially if the catalog is new and unfamiliar to you. Here are severaldifferent 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 adesign 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 designpatterns.