If you are not completely familiar with the patterns then this is probably the hardest part. My struggle was that I have a program to build and I want to make flexible and easy. Everyone seems to be using Factories and Abstract Factories, and I want to build my project using Factories, right? Well, wrong approach! Maybe and maybe not, but we need to know more.
Don't try to fit patterns into your project until you understand the problem you are trying to solve and the pattern that may solve that problem. So what we really need to do is learn the problems that are solved by the patterns and to be able to recognize them so that we can put the RIGHT patterns into our project in the RIGHT places.
Patterns / Problems / Solutions
Table below is from page 10 of GoF.
|
Purpose |
|
Creational |
Structural |
Behavioral |
| Scope |
Class |
Factory Method(107) |
Adapter(class)(139) |
Interpreter(243)
Template Method(325) |
| Object |
Abstract Factory(87)
Builder(97)
Prototype(117)
Singleton(127) |
Adapter(object)(139)
Bridge(151)
Composite(163)
Decorator(175)
Facade(185)
Flyweight(195)
Proxy(207) |
Chain of Responsibility(223)
Command(233)
Iterator(257)
Mediator(273)
Memento(283)
Observer(293)
State(305)
Strategy(315)
Visitor(331) |
Creational: Creational patterns are concerned with object creation.
- Creational class pattern: defer some part of object creation to subclasses.
- Creational object pattern: defer object creation to another object.
Behavioral: Characteristic the way classes interact and distribute responsibility.
Most objects are 'object' scope: think 'prefer composition to inheritance'.
Patterns often rely on other patterns: Composite is often used with Visitor or Iterator.
Patterns may have alternatives: Prototype, Abstract Factory
Paterns may have similar design but different intent: Composite, Decorator
Finding Objects:
Many objects in design come from doing an analysis model, such as the 'noun-verb' approach, but you will end up with objects that have no real world counterpart (rwcp).Abstractions such as arrays are an example of an object that does not have a rwcp. These abstraction make your code more flexible, so keep your mind open about objects that may help your design even if there is no rwcp for that object.
Process Abstractions:
How about an object that represents an action. The conventional OOP theory is that since objects do actions (noun-verb approach) you build classes to represent the nouns and you have functions to represent the actions.
You could build classes to represent actions (aka: Algorithm Objects) so that you can add the action object to noun object at run-time, using composition, . This is the principle behind the 'Strategy Pattern'.
Visitor & Command
Produce objects with the sole responsibility of issuing a request on another object or group of objects.
Flyweight
How to support huge numbers of objects at the finest granularity.