Let review the book “Design Patterns Elements of Reusable Object-Oriented Software” book with me to understand famous concept “Design Pattern”
1. What is a Design Pattern?
It is defined by “The Gang of Four” authors as: The design patterns are descriptions of communicating objects and classes that are customized to solve a general design problem in a particular context.
For short, a design pattern is a common solution for a common problem.
2. Why do we need Design Pattern?
Based on its definition, we can guess some advantage when using Design Pattern:
- make it easier to reuse successful design and architecture.
- expressing proven techniques as design patterns make them more accessible to developers of new system.
- help you choose design alternatives that make a system reusable and avoid alternatives that compromise re-usability.
- improve the document and maintenance of existing systems
Owning design pattern skills helps us solve common problems faster in more effective way.
3. How to classify Design Pattern?
We can classify design patterns based on their purpose, reflect what patterns do:
- Creational patterns: concern process of object creation.
- Abstract Factory
- Builder
- Factory Method
- Prototype
- Singleton
- Structural patterns: deal with the composition of classes objects.
- Adapter
- Bridge
- Composite
- Decorator
- Facade
- Flyweight
- Proxy
- Behavioral patterns: characterize the ways in which classes or objects interact and distribute responsibility.
- Chain of Responsibility
- Command
- Interpreter
- Iterator
- Mediator
- Memento
- Observer
- State
- Strategy
- Template Method
- Visitor
3. Choose the first steps
23 Design Patterns can confuse you at the first look. So I listed here the essential Design Patterns as our first step.
3.1. Singleton
- Intent: ensure a class only has one instance, and provide a global point of access to it.
- Applicability:
- there must be exactly one instance of a class, and it must be accessible to clients from a well-known access point.
- when the sole instance should be extensible by subclassing, and clients should be able to use an extended instance without modify their code
3.2. Factory method
- Intent: define an interface for creating object, but let sub-classes decide which class to instantiate. Factory Method lets a class defer instantiation to sub-classes.
- Applicability:
- a class can’t anticipate the class of object it must create.
- a class wants its subclasses to specify the objects it creates.
- classes delegate responsibility to one of several helper subclasses, and you want to localize the knowledge of which helper subclass is the delegate.
3.3. Builder
- Intent: separate the construction of a complex object from its representation so that the same construction process can create different representations.
- Applicability:
- the algorithm for creating a complex object should be independent of the parts that make up the object and how they’re assembled.
- the construction process must allow different representations for the objects that’s constructed.
3.4. Adapter
- Intent: convert the interface of a class into another interface clients expect. Adapter lets classed work together that couldn’t otherwise because of incompatible interfaces.
- Applicability:
- you want to use an exiting class, and its interface does not match the one you need.
- you want to create a reusable class that cooperates with unrelated or unforeseen classes, that is, classes that don’t necessarily have compatible interfaces.
- you need to use several existing subclasses, but it’s impractical to adapt their interface by subclassing every one. An object adapter can adapt the interface of its parent class.
3.5. Observer
- Intent: define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and update automatically.
- Applicability:
- when an abstraction has two aspects, one dependent on the other
- when a change to one object requires changing others, and you don’t know how many objects need to be changed.
- when an object should be able to notify other objects without making assumption about who these objects are. In other words, you don’t want these object tightly coupled.
3.6. State
- Intent: allow an object to alter its behavior when its internal state changes. The object will appear to change its class.
- Applicability:
- an object’s behavior depends on its state, and it must change its behavior at run-time depending on that state.
- operations have large, multi part conditional statements that depend on the object’s state.
3.7. Strategy
- Intent: define a family of algorithms, encapsulate each one, and make the minter changeable. Strategy let the algorithm vary independently from clients that use it.
- Applicability:
- many related classes differ only in their behavior. Strategies provide a way to configure a class with one of many behavior.
- you need different variants of an algorithm.
- an algorithm uses data that clients shouldn’t know about. Use strategy pattern to avoid exposing complex, algorithm-specific data structures.
- a class defines many behaviors, and these appear as multiple conditional statements in its operations. Instead of many conditionals, move related conditional branches into their own strategy class.
4. What should we do next?
Let focus on above begin design patterns on detail first. After understanding and practicing a lot to apply it into real world, we can expand to all design patterns.
5. Reference
Thanks “The Gang of Four” authors for great book “Design Patterns Elements of Reusable Object-Oriented Software”.
