The architect Christopher Alexander, who mentioned how patterns can be used to address common design issues, originally documented the concept. The idea came about from Alexander; he proposes that design issues can be documented rigorously, alongside their proposed solution. Design patterns have most notably been applied to resolving architectural issues in software design.
In Christopher Alexander's own words:
"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."
Alexander wrote his own book, predating the Gang of Four called, A Pattern Language. In this book, Alexander created his own language, he coined the phrase pattern language to describe this; this language was formed from the building blocks of Architectural patterns. By utilizing these Architectural patterns the book proposes that ordinary people can use this language as a framework to improve their neighborhoods and towns.
One such pattern that is documented in the book is Pattern 12, known as the Community of 7000; the book documents this pattern by stating the following:
"Individuals have no effective voice in any community of more than 5,000-10,000 persons."
By using problems such as this one with their documented solution; the book ultimately forms patterns, these patterns seek to act as the building blocks for making communities better.
As I mentioned, Alexander predated the Gang of Four; but his work was essential for sowing the seeds for software design patterns.
Now, let's turn directly on to the authors known as The Gang of Four.
Nope, we're not referring to the 1981 defectors from the British Labour party or an English post-punk band; but we are talking about the authors of a book called Design Patterns: Elements of Reusable Object-Oriented Software. This book has been highly influential in the realm of software development and is well known in the software engineering field.
In the first chapter of the book, the authors discuss object-oriented software development from their own personal experience; this includes arguing how software developers should program for an interface and not an implementation. This leads to code ultimately utilizing central functions of object-oriented programming.
It is a common misconception that the book contains only four design patterns, this isn't true; it covers 23 design patterns from three fundamental categories.
Let's cover what these categories are:
Creational
Structural
Behavioral
So let's break each one of these down.
Creational design patterns concern the creation of objects themselves. Basic instantiation of classes without using a design pattern can result in needless complexity, but also in significant design problems.
The main usage of Creational design patterns is to separate the instantiation of a class from the usage of that instance. Failure to use Creational design patterns can mean your code is harder to understand and test.
Dependency injection is the process whereby you can actually input dependencies that your application needs directly into the object itself.
John Munsch left an answer on Stack Overflow called Dependency injection for five year olds, this answer was republished in the book Mark Seeman's Dependency Injection in .NET:
Tip
When you go and get things out of the refrigerator for yourself, you can cause problems. You might leave the door open, you might get something Mommy or Daddy doesn't want you to have. You might even be looking for something we don't even have or which has expired.
Tip
What you should be doing is stating a need, "I need something to drink with lunch," and then we will make sure you have something when you sit down to eat.
When writing a class, it's natural to use other dependencies; perhaps a database model class. So with dependency injection, instead of a class having its database model created in itself, you can create it outside that object and inject it in. In short, we separate our client's behavior from our client's dependencies.
When thinking of dependency injection, let's outline the four separate roles involved:
The service to be injected
The client that depends on the service being injected
The interface that determines how the client can use the service
The injector that is responsible for instantiating the service and injecting it into the client
Structural design patterns are fairly easy to explain, they act as interconnectors between entities. It serves as a blueprint for how basic classes can be combined to form bigger entities, all Structural design patterns involve the interconnections between objects.
Behavioral design patterns work to explain how objects interact with each other; how they can send messages between each of the objects and how you can divide the steps of various tasks up among classes.
Structural patterns describe the static architecture of a design; Behavioral patterns are more fluid and describe a flowing process.
This is not strictly a design pattern (but the Gang of Four didn't cover Architectural patterns in their book); but it is incredibly relevant for PHP developers due to the web-oriented nature of PHP. Architectural patterns address various different constraints in computer systems through addressing performance limitations, high availability, and also minimization of business risk.
Most developers will be familiar with the Model-View-Controller architecture when it comes to web frameworks, more recently other architectures have started to emerge; for example, a microservices architecture works by a set of RESTful APIs that are independent and interconnected. Some people believe microservices move problems from the software development layer to the systems architecture layer. The opposite of microservices often referred to as a monolithic architecture, is where all the code is together in one application.