Appendix A: A Brief Overview of GoF Design Patterns
We all have unique thought processes. So, in the early days of software development, engineers faced a common problem—there was no standard to instruct them how to design their applications. Each team followed their own style, and when a new member (experienced or unexperienced) joined an existing team, understanding the architecture was a gigantic task. Senior or experienced members of the team would need to explain the advantages of the existing architecture and why alternative designs were not considered.
The experienced developer also knows how to reduce future efforts by simply reusing the concepts already in place. Design patterns address this kind of issue and provide a common platform for all developers. You can think of them as the recorded experience of experts in the field. Patterns were intended to be applied in object-oriented designs with the intention of reuse.
In 1994, Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides published the book
Design Patterns: Elements of Reusable Object-Oriented Software
(Addison-Wesley). In this book, they introduced the concept of design patterns in software development.
These authors became known as the Gang of Four. I refer to them as the “GoF” throughout this book
. The GoF described 23 patterns that were developed by the common experiences of software developers over a period of time. Nowadays, when a new member joins a development team, the developer is expected to know about the design patterns, and then the developer learns about the existing architecture. This approach allows a developer to actively participate in the development process within a short period of time.
The first concept of a real-life design pattern came from the building architect Christopher Alexander. During his lifetime, he discovered that many of the problems he faced were similar in nature. So, he tried to address those issues with similar types of solutions.
Each pattern describes a problem, which 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
The
software engineering community
started believing that although these patterns were described for buildings and towns, the same concepts could be applied to patterns in object-oriented design. They felt that we could substitute the original concepts of walls and doors with objects and interfaces. The common thing in both fields is that, at their cores, patterns are solutions to common problems.
Lastly, it is important to note that the GoF discussed the original concepts of design patterns in the context of C++. But
Sun Microsystems
released its first public implementation of Java 1.0 in 1995, and then it went through various changes. In 1995, Java was totally new to the programming world. But it grew rapidly and secured its rank in the world’s top programming languages within a short period of time, and in today’s market, it is always in high demand. (You may know that later Oracle Corporation acquired Sun Microsystems and the acquisition process was finished on January 27, 2010.)
On the other hand, the concepts of design patterns are universal. So, when you exercise the fundamental concepts of design patterns with Java, you will be a better programmer, and you’ll remake yourself in the programming community.
Key Points
A design pattern describes a general
reusable solution
to software design problems. While developing software, you may encounter these problems frequently. The basic idea is that you can solve similar kinds of problems with similar kinds of solutions. And these solutions were tested over a long period of time.
Patterns provide a template of how to solve a problem. They can be used in many different situations. At the same time, they help you get the best possible design much faster.
Patterns are descriptions of how to create objects and classes, and customize them to solve a general design problem in a particular context.
The GoF discussed 23 design patterns. Each of these patterns focuses on a particular
object-oriented design
. Each pattern can also describe the consequences and trade-offs of use. The GoF categorized these 23 patterns based on their purposes, as shown in the following sections.
A. Creational Patterns
Creational patterns
abstract the instantiation process. You make the systems independent from the way that their objects are composed, created and represented. In these patterns, you are concerned about “Where should I place the “new” keyword in my application?” This decision can determine the degree of coupling in your classes. The following five patterns belong in this category.
Singleton pattern
Prototype pattern
Factory method pattern
Builder pattern
Abstract factory pattern
B. Structural Patterns
Structural patterns
focus on how classes and objects can be composed to form a relatively large structure. They generally use inheritance or composition to group different interfaces or implementations. Your choice of composition over inheritance (and vice versa) can affect the flexibility of your software. The following seven patterns fall into this category.
Proxy pattern
Flyweight pattern
Composite pattern
Bridge pattern
Facade pattern
Decorator pattern
Adapter
pattern
C. Behavioral Patterns
Behavioral patterns
concentrate on algorithms and the assignment of responsibilities among objects. They focus on communication between them and how objects are interconnected. The following 11 patterns fall into this category.
The GoF made another classification based on scope, namely whether the pattern primary focuses on the classes or its objects. Class patterns deal with classes and subclasses. They use inheritance mechanisms, so they are static and fixed at compile time. Object patterns deal with objects that can change at runtime. So, object patterns are dynamic.
For a quick reference, you can refer to the following
table
, which was introduced by the GoF.
Q&A Session
- 1.
What are the differences between class patterns and object patterns?
In general,
class patterns
focus on static relationship but object patterns can focus on dynamic relationships. As name suggests, class patterns focus on classes and its subclasses and
object patterns
focus on the objects relationships.
As per GoF, these patterns can be further differentiated in Table
A-1
Table A-1Class Patterns vs Object Patterns
| Class Patterns | Object Patterns |
---|
Creational
| Defers object creation to its subclasses. | Defers object creation to another object. |
Structural
| Focuses on the composition of classes (primarily uses the concept of inheritance). | Focuses on the different ways of composition of objects. |
Behavioral
|
Describes the algorithms and execution
flows
.
| Describes how different objects can work together and complete a task. |
.
- 2.
Can I combine two or more patterns in an application?
Yes. In real-world scenarios, this type of activity is common.
- 3.
Do these patterns depend on a particular programming language?
Programming languages
can play an important role. But the basic ideas are same, patterns are just like templates and they give you some idea in advance of how you can solve a particular problem. In this book, I primarily focused on object-oriented programming with the concept of reuse. But instead of any object-oriented programming language, suppose you have chosen some other language like C. In that case, you may need to think about the core object-oriented principles such as inheritance, polymorphism, encapsulation, abstraction, and so on, and how to implement them. So, the choice of a particular language is always important because it may have specialized features that can make your life easier.
- 4.
Should I consider common data structures like arrays and linked lists as design patterns?
The GoF clearly excludes those saying that
they are not complex, domain-specific designs for an entire application or subsystem
. They can be encoded in classes and reused as is. So, they are not your concern in this book.
- 5.
If no particular pattern is 100% suitable for my problem, how should I proceed?
An infinite number of problems cannot be solved with a finite number of patterns, for sure. But if you know these common patterns and their trade-offs, you can pick a close match. No one prevents you from using your own pattern for your own problem, but you have to tackle the risk.
- 6.
Do you suggest any general advice before I jump into the topics?
I always follow the footsteps of my seniors and teachers who are experts in this field. And the following are general suggestions from them.
Program to a supertype(Abstract class/Interface), not an implementation.
Prefer composition over inheritance.
Try to make a loosely coupled system.
Segregate the code that is likely to vary from the rest of your code.
Encapsulate what varies.
- 7.
How can I use this book effectively?
This book focuses on commonly used design patterns. Most likely, you face them very often in your everyday life. But the world is always changing, and new patterns are keep evolving. To understand the necessity of a new pattern, you may also need to understand why an old/existing pattern is not enough to fulfil the requirement. You may consider this book as an attempt to make a solid foundation with design patterns, so that, you can move smoothly in your professional life and you can adapt the upcoming changes easily.