Design patterns
After a long time away from posting, as I couldn’t find the moment nor the subject, I’ve decided to do it again, motivated by the thread A post a day keeps the doctor away written by my dear workmate Angel “Java” Lopez.
What I lacked was the subject, as I was decided to make a strong comeback, with something in particular for everyone. I was able to find that subject during my study about design patterns. I searched… and searched… and searched, but the lack of content in the net was surprising (in particular, in some places where there were too many inconsistencies).
After reading some books, webs and blogs, I realized that what one had, another one was missing, so I’ve decided to make a concrete description of some of them.
However, I’d like to make clear that I’ll deal with what a design pattern is. When and how to choose one in particular, how they solve design problems and how a pattern is used (by this I mean, the steps the reader should follow to put one in practice, and not its implementation) are out of the scope of this topic.
Having said this, I’d like to say, too, that any type of comment or feedback will be welcome. This way, this topic could be corrected and updated so that it can provide a base source for any reader interested in this subject.
What’s a design pattern?
Well, now, let’s focus on the subject: design patterns. First of all, I’d like to do some kind of definition “inheritance“, going from the generic definitions to the specific ones.
Let’s start with the most abstract definitions:
- Model or sample that is used to get another one of the same kind.
- Accepted reference used to define a measure unit.
- Model used as reference to measure or value another one of the same kind.
Peculiarly, these three definitions show a pattern, a common model; they point to the same thing. They indicate that a pattern is a reference used as a model to measure, value and make another one of the same kind. This is my interpretation. Simple and concrete, isn’t it? It seems to me that it is a correct definition to provide a base concept from which we will start to “inherit”.
Let’s continue with the pattern concept. in his book, A Timeless Way Of Building, Christopher Alexander indicates that “each pattern is a three-part rule, which expresses a relation between a certain context, a problem, and a solution.
As an element in the world, each pattern is a relationship between a certain context, a certain system of forces which occurs repeatedly in that context, and a certain spatial configuration which allows these forces to resolve themselves.
As an element of language, a pattern is an instruction, which shows how this spatial configuration can be used, over and over again, to resolve the given system of forces, wherever the context makes it relevant.
The pattern is, in short, at the same time a thing, which happens in the world, and the rule which tells us how to create that thing, and when we must create it. It is both a process and a thing; both a description of a thing which is alive, and a description of the process which will generate that thing.”
I’ll stop here to mark what made me quote these paragraphs. Alexander indicates that a pattern a three-part rule (context-problem-solution), a thing that indicates us how and when we must create it to resolve a given system in a relevant context. This shows that a pattern can describe a certain problem, a particular situation for that problem, and a solution in the same given context.
Now, let’s get into something more specific for our subject. Alexander tells us (in his book A Pattern Language) that “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.“. This definition is pretty interesting. The first time I saw it was in the post The Bridge Pattern from the Mathew Nolton’s blog, in which Nolton remarks the part that says that a pattern describes “[...] the core of the solution to that problem […]”, emphasizing that understanding that problem can lead us to understand the why of when we should use which pattern. I mean, if we understand our problem, we will use a certain pattern and adapt it to our context.
Let’s get into what a design pattern is. Let’s see the definition provided by Erich Gamma (in his book Design patterns):
“A design pattern names, abstracts, and identifies the key aspects of a common design structure that make it useful for creating a reusable object-oriented design. The design pattern identifies the participating classes and instances, their roles and collaborations, and the distribution of responsibilities. Each design pattern focuses on a particular object-oriented design problem or issue. It describes when it applies, whether it can be applied in view of other design constraints, and the consequences and trade-offs of its use.”
This definition erases any possible doubt. It concretely explains what a design pattern is, but Gamma doesn’t stop there and explains that “[...] a pattern is like a template that can be applied in many different situations. Instead, the pattern provides an abstract description of a design problem and how a general arrangement of elements”. I think that with this I’ll be closing the concept. These statements add value to the definition as they indicate that a design pattern provides a template, a default format of a solution, a set of tools that we can use in a customized way to fit our particular situation. I mean, a design pattern deals with a particular problem, yes, but it’s up to us to adapt it to our particular case, our concrete context. To see this, you simply have to remember Alexander’s definition.
Having a clear concept, what else should we know about design patterns? Gamma tells us that a pattern generally has four essential elements:
- The pattern name: it describes, in a word or two, a design problem, its solutions, and consequences.
- The problem describes when to apply the pattern (it explains the problem and its context).
- The solution describes the elements that make up the design, their relationships, responsibilities, and collaborations.
- The consequences are the results and trade-offs of applying the pattern. They often concern space and time trade-offs, as well as the impact on a system’s flexibility, extensibility, or portability.
And then he classifies them according to their purpose (what the pattern does) and its scope (classes or objects):
Scope
Class patterns deal with relationships between classes and its subclasses established through inheritance (static relationships, at compile-time). While object patterns deal with relationships among objects (dynamic relationships, at run-time).
Purpose
Creational Patterns
deal with the process of creating objects. Creational class patterns delegate some part of the object creation operations to subclasses, while creational object patterns delegate some part of the object creation operations to another object.
Structural Patterns deal with composition of classes or objects. Structural class patterns use inheritance to compose classes, while structural object patterns describe ways to assemble objects.
Behavioral Patterns characterize the ways in which classes or objects interact and distribute responsibility. Behavioral class patterns use inheritance to describe to a chain of actions or algorithms, while behavioral object patterns define how a group of objects interact to perform one task that no single object can perform on its own.
With this, I’ll be closing the subject. here, I’m leaving a list of patterns that, once I deal with each one, will have a link to its posts.
Creational Patterns:
- Abstract Factory
- Builder
- Factory Method
- Prototype
- Singleton
Structural Patterns:
- Adapter
- Bridge
- Composite
- Decorator
- Façade
- Flyweight
- Proxy
Behavioral Patterns:
- Chain of Responsibility
- Command
- Interpreter
- Iterator
- Mediator
- Memento
- Observer
- Cheers, Nacho
PS: Some interesting references:
Ver este topic en español.