Why Use Design Patterns?
In one word: practicality. Have you had a recurring problem and thought there has to be a better way? That’s where a pattern comes into play. As with everything, there are many problems we have to solve, and finding a common solution can avoid mistakes, save time, and be recognizable by others.
What Is a Design Pattern?
In Part 2, we discussed the SOLID and STUPID principles designed to help you create cleaner, less tightly-coupled code. As you may have noticed in the examples, certain patterns began to appear to help make your code more SOLID. It probably won’t surprise you to learn that the next step to writing SOLID code is implementing design patterns.
A design pattern is a solution to a problem that occurs over and over again. To quote a famous architect who built towns and buildings:
The elements of this language are entities called patterns. Each pattern describes a problem that occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice. — Christopher Alexander, A Pattern Language: Towns, Buildings, Construction, Oxford University Press, USA, p. 1216.
What Christopher says perfectly translates to object-oriented design patterns. By using them, we get many benefits, including:
Reusability.
Solutions to common programming problems.
Shorter development time.
Reliability (they are well-proven).
Clarity to the system architecture, and the possibility of building a better system.
Does this sound a little familiar? Yes, because the SOLID principles go hand-in-hand with design patterns. As you learn about design patterns, you will notice that you probably already use some and didn’t realize it. That’s great! The idea is to become aware of them and learn when to use them.
In general, a design pattern has four elements:
Pattern name
Problem (when to apply the pattern)
Solution (elements that make up the design)
Consequences (results and trade-offs of applying the pattern)
So, where did software design patterns come from?
Gang of Four
It wasn’t until 1994 that design patterns gained popularity, thanks to the work of Eric Gamma, Ralph Johnson, Richard Helm, and John Vlissides.
These four developers are considered the Gang of Four (GoF). They established 23 patterns divided into three groups:
Creational – for object creation
AbstractFactory: Creates an instance of several families of classes.
Builder: Separates object construction from its representation.
FactoryMethod: Creates an instance of several derived classes.
Prototype: A fully initialized instance to be copied or cloned.
Singleton: A class of which only a single instance can exist.
Structural– for building large complex objects
Adapter: Match interfaces of different classes.
Bridge: Separates an object’s interface from its implementation.
Composite: A tree structure of simple and composite objects.
Decorator: Add responsibilities to objects dynamically.
Facade: A single class that represents an entire subsystem.
Flyweight: A fine-grained instance used for efficient sharing.
Proxy: An object representing another object.
Behavioral – for algorithms and relationships with objects
Chain of Responsibility: A way of passing a request between a chain of objects.
Command: Encapsulate a command request as an object.
Interpreter: A way to include language elements in a program.
Iterator: Sequentially access the elements of a collection.
Mediator: Defines simplified communication between classes.
Memento: Capture and restore an object’s internal state.
Observer: A way of notifying change to several classes.
State: Alter an object’s behavior when its state changes.
Strategy: Encapsulates an algorithm inside a class.
TemplateMethod: Defer the exact steps of an algorithm to a subclass.
Visitor: Defines a new operation to a class without change.
How do I know when I will need to use a design pattern?
Great question! Learning design patterns are great, but knowing when to use one or more in the real world takes time. Why? Because it's as you grow as a developer that you begin to see these recurring problems and go, “Hey, I’ve seen this before, and I know how to deal with it!”
In the following chapters, we are going to explore a number of these design patterns in more detail. Plus, you’ll discover how to recognize when to use one.
Let’s Recap!
A design pattern is a solution to a recurring problem.
Design patterns are reusable, express proven techniques, and help make a better system.
A design pattern has four elements: pattern name, problem, solution, and consequences.
In 1994, the Gang of Four published their book, Design Patterns: Elements of Reusable Object-Oriented Software, containing 23 design patterns divided into three groups: creational, structural, and behavioral.
Now that you understand the value of design patterns, let’s look at some examples in the first group: creational.
