Originally posted by Patricia Samuel:
I have just started to study Desgin Patterns. I am using Head First by K&B.
Actually
Head First Design Patterns is by Eric Freeman and Elisabeth Freeman
with Kathy Sierra and Bert Bates.
Yes it seems to be startegy pattern as class will have different alogrithm and it will be decided dynamically.
In your initial example
nothing is decided
dynamically. The class1 (not a class2) instance is "created" regardless. Also no result is ever captured from the execution of "i.method()" so its unlikely that "method()" actually represents an algorithm. So for all we know class1 is a actually an implementation of the Command Pattern with an oddly named "execute()" method.
Which brings up an important point. Design Patterns are recurring solutions to similar
problems. In this case we have no idea what
problem is that is being solved - design patterns only make sense in the context of the problem that they are solving.
So effective use of Design Patterns requires that you can clearly discern the problem that you are trying to solve. If the problem belongs to a set of similar problems that are addressed by a particular pattern then that pattern
may help you.
GoF established a standard pattern template:
Pattern Name and Classification - The pattern's name conveys the essence of the pattern succinctly. A good name is vital, because it will become part of your design vocabulary. Intent - A short statement that answers the following questions: What does the design pattern do? What is its rationale and intent? What particular design issue or problem does it address? Also Known As - Other well-known names for the pattern, if any. Motivation - A scenario that illustrates a design problem and how the class and object structures in the pattern solve the problem. Applicability - What are the situations in which the design pattern can be applied? What are examples of poor designs that the pattern can address? How can you recognize these situations? Structure - A graphical representation of the classes in the pattern. Participants - The classes and/or objects participating in the design pattern and their responsibilities. Collaborations - How the participants collaborate to carry out their responsibilities. Consequences - How does the pattern support its objectives? What are the trade-offs and results of using the pattern? What aspect of system structure does it let you vary independently? Implementation - What pitfalls, hints, or techniques should you be aware of when implementing the pattern? Are there language-specific issues? Sample Code - Code fragments that illustrate how you might implement the pattern. Known Uses - Examples of the pattern found in real systems. Related Patterns - What design patterns are closely related to this one? What are the important differences? With which other patterns should this one be used? The problem that you are trying to solve should be at least in part addressed by the pattern's
Intent.
Examples:
Strategy: Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it.Decorator: Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality.Command: Encapsulate a request as an object, thereby letting you parameterize clients with different requests, queue or log requests, and support undoable operations Factory Method: Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses. Abstract Factory: Provide an interface for creating families of related or dependent objects without specifying their concrete classes. If the
Intent sounds like a possible solution to your problem then the
Motivation will usually raise issues that are similar to the problems that you are facing.
Applicability should reinforce that the pattern is in fact a suitable solution to your problem - at the same time it may raise issues that prevent you from using the pattern in your particular situation.
Structure lays out the scope of the pattern and identifies the
Participants. Each participant has its own responsibility and
collaborates with other participants to complete the mechanics of the pattern. To solve your particular problem some particpants will have to be created from scratch while others may already exist in your system. The
Consequences of using the pattern describes what further constraints may be placed on your system through the use of the pattern - some consequences may prevent you from using the pattern in your system.
Related Patterns may identify patterns that are more suited to your particular problem.
In the end there may not be a pattern to solve your particular problem.
Also trying to identify patterns from "code" without a problem context isn't a suitable way to learn the effective use of design patterns - every OO language implements OO patterns slightly differently, each according to their own features and capabilities (some don't even need some of them). Design patterns are implemented in code but they are more abstract than code.
There is a finite number of identified patterns while there are infinite variations of problems which means that not all the problems can be addressed by a pattern - in fact for majority of
interesting problems there isn't a pattern. Fortunately there are Object-Oriented Design Principles that can also be applied in infinite variations.
HFDP p. 31
Guru: There are some object-oriented principles that underlie patterns, and knowing these will help you to cope when you can't find a pattern that matches your problem.
The Object-Oriented Principles/Practices discussed in HFDP are
Commonality-Variability Analysis: Identify the aspects that vary and separate them from what stays the same (p. 9) Program to an interface, not an implementation (p. 11) Favor composition over inheritance (p. 23) "Strive for loosely coupled design between objects that interact" (p.53) / Principle of Least Knowledge (p.265) Open-Closed Principle (p.86) Dependency Inversion Principle (p.139) "Don't call us, we'll call you" (p.296) which usually results in the use of Dependency Injection. Single Responsibility Principle (p.337) The patterns discussions in HFDP are primarily case studies of recurring solutions to similar problems that were arrived at through skillfull application of Object-Oriented Principles and Practices! By mastering the Object-Oriented Principles and Practices you will not only have an easier time with Design Patterns but you will also be better equipped to face all sorts of other design challenges. Design Patterns only exist so that you don't have to "re-invent the wheel" every time you solve a similar problem. The "Object-Oriented Principles and Practices" should always be your first tool of choice - patterns only come into play once you realize that there is something "familiar" about the problem (because of the
Intent,
Motivation, and
Applicability sections of the patterns that you have studied). In addition pattern names can make communicating with your peers more effective as everybody should know what you are talking about when you mention, for example, "Strategy" - it shouldn't be necessary to discuss the nitty-gritty details of the Strategy as it is a well documented pattern.
Apply Patterns Gently Agile Software Development: Principles, Patterns, and Practices is a good resource in case you want to learn more about Object-Oriented Principles and Practices.
[ May 01, 2008: Message edited by: Peer Reynders ]