While the first publication of the Gang of Four's Design Patterns: Elements of Reusable Object-Oriented Software was released in October of 1994, I have only been paying attention to design patterns for seven or eight years. Like most experienced developers, when I first started reading about design patterns, I recognized a lot of the patterns because I had already been using them without realizing what they were. I would have to say that in the past seven or eight years since I first read about design patterns, I have not written a serious application without using at least one of the Gang of Four's design patterns. I will tell you that I am definitely not a design pattern zealot and, if I get into a conversation about design patterns, there are usually only a couple of them that I can name without having to look them up. But one thing that I do remember is the concepts behind the major patterns and the problems they are designed to solve. This way, when I encounter one of these problems, I can look up the appropriate pattern and apply it. So remember, as you go through this chapter, to take the time to understand the major concepts behind the design patterns rather than trying to memorize the patterns themselves.
In this chapter, you will learn about the following topics:
Every experienced developer has a set of informal strategies that shape how he or she designs and writes applications. These strategies are shaped by their past experiences and the obstacles that they have had to overcome in their previous projects. While these developers might swear by their own strategies, it does not mean that their strategies have been fully vetted. The use of these strategies can also introduce inconsistent implementations between different projects and developers.
While the concept of design patterns dates back to the mid 80s, they did not gain popularity until the Gang of Four released their Design Patterns: Elements of Reusable Object-Oriented Software book, published in 1994. The book's authors, Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides (also known as the Gang of Four), discuss the pitfalls of object-oriented programming and describe 23 classic software design patterns. These 23 patterns are broken up into three categories: creational, structural, and behavioral.
A design pattern identifies a common software development problem and provides a strategy to deal with it. These strategies have been proven, over the years, to be an effective solution for the problems they are intended to solve. Using these patterns can greatly speed up our development process because they provide us with solutions that have already been proven to solve several common software development problems.
Another advantage that we get when we use design patterns is consistent code that is easy to maintain because, months or years from now, when we look at our code, we will recognize the patterns and understand what the code does. If we properly document our code and document the design pattern we are implementing, it will also help other developers understand what our code is doing.
The two main philosophies behind design patterns are code reuse and flexibility. As a software architect, it is essential that we build reusability and flexibility into our code. This allows us to easily maintain our code in the future and also makes it easier for our applications to expand to meet future requirements because we all know how quickly the requirements change.
While there is a lot to like about design patterns and they are extremely beneficial for developers and architects, they are not the solution for world hunger that some developers make them out to be. Sometime in your development career, you will probably meet a developer or an architect who thinks that design patterns are immutable laws. These developers usually try to force the use of design patterns even when they are not necessary. A good rule of thumb is to make sure that you have a problem that needs to be fixed before you try to fix it.
Design patterns are starting points for avoiding and solving common programming problems. We can think of each design pattern as a recipe for a food dish. Just like a good recipe, we can tinker and adjust it to meet our particular tastes. But we usually do not want to stray too far from the original recipe because we may mess it up.
There are also times when we do not have a recipe for a certain dish that we want to make just like there are times when there isn't a design pattern to solve the problem we face. In cases like this, we can use our knowledge of design patterns and their underlying philosophy to come up with an effective solution for our problem.
Design patterns are split into three categories. They are as follows:
While the Gang of Four defined over 20 design patterns, we are only going to look at examples of some of the more popular patterns in this chapter. Let's start off by looking at creational patterns.
Design patterns were originally defined for object-oriented programming. In this chapter, where possible, we will focus on implementing the patterns in a more protocol-oriented way. Therefore, the examples in this chapter may look a little different from examples in other design pattern books, but the underlying philosophy of the solutions will be the same.