We will write a series about some important and useful design patterns . Most of them you probably know about, some you migt be using already, some you might be using without thinking about it and hopefully some are new to you. Even though I’m well aware that most of them has been written about many times I thought we all need some repetition, can't hurt right? It is also a good way for me to have it documented close-and-handy.
What we will do is to bring up the pros and cons about the patterns and how they could and should be used. Will try to exemplify them in easy ways and how we have used them.
Patterns
There are a couple of pattern types one of which is the Design Patterns. The design patterns are patterns that are described by software design constructs, such as objects, classes, inheritance or you could say they are described with code. These are the patterns that I will be focused on, but other types might appear as well.
Other types of patterns are architectural patterns, which are patterns to describe more organizational structures. Could be a pattern that describes the relationship between the object Person, Employee and Address. These are patterns that are described by building blocks and structures, one classic pattern is the "Three-Layered services application architecture pattern", as you can see in the image. Another type of pattern is the Idioms or coding patterns that some call them. Idioms are very low-level and more specific to languages.
Design patterns: what, why and how?
First and foremost it is important to clarify what Design Patterns really are:
A pattern is an abstraction of concrete solutions that reoccur in non-arbitrary contexts
The purpose is to encapsulate and abstract common problems to a well-known and well-structured solution, a pattern. Patterns should be a map of a solution to a common problem. A map that can be used over and over again. Even though they are very well tested you as the interpreter of the map have to understand the map to really make use of the power Otherwise it can lead to the opposite - failure.
Another good statement that could help explain the meaning of patterns was mentioned in this paper "Christopher Alexander: an Introduction for Object-Oriented Designers" was:
Each pattern encapsulates a well-defined problem and its solution in a particular domain
The why of using patterns comes down to that they are supposed to represent well tested solutions to problems that are reoccurring. It’s all about best practices and lessons that should’ve been learned already. Why reinvent the wheel?
It is important not to over-use these types of patterns and they should be used only when you really understand them. It is otherwise really easy to misuse them, which could lead to totally different result. The how in patterns is hopefully something that will be explained in each separate post below.
Index of design patterns
| Type | Name | Description |
| Creational pattern | Singleton pattern | a pattern to ensure that one specific class is only initiated once and that there is only one global access point |
References
Here are some really good references for you if you want to dig deeper into the world of patterns.
- A good starting point is the website of the Patterns & Practices initiative of Microsoft.
- Another great overview of general design patterns for computer science is Wikipedia's overview
- A background of design patterns and some history about them