When we arrive to the world of object oriented programming (OOP), one of the first terms we encounter is design patterns.

Design patterns are important stuff, and we really need to understand them.

As everything in life, some of these patterns are easier to understand than others, but as long as you have understood the principles of OOP as inheritance, composition , polymorphism and encapsulation and have your mind oriented to think in the “object way” you will be half way there.

Design patterns are probably one of the most influential development strategies that came out of the minds behind the OOP thinkers and comes hand to hand with software reuse.

So the first question we normally put to ourselves is :

What are these Design Pattern things ?

Design patterns represent the best practises to solve a particular type of problem, being that by best practises we refer to well documented, well tested and efficient solutions.
In fact, when we have a well tested and efficient solution that can be applied and re - applied successfully to a certain kind of problem, we are facing a pattern. This can be applied not only to software, but to many other things in our human world.

Who invented this stuff ?

Well, the true is that there is no single master mind behind this design patterns, however we can consider the book Elements of reusable object oriented software as the milestone that has established the principles. Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides,the authors of the book, have in fact become so popular that they are referred as the Gang of Four or GOF.

So, next time you ear someone talk about the GOF patterns, you know they are talking about the principles presented in those guys book.

Why do I need to learn them ?

We, as developers, need tools. By tools, here, we do not mean software tools, but knowledge that can allow us to carry out our job in the most efficient manner.

So, if someone has invented an efficient way to solve a problem, we obviously should use it when we face the same kind of problem (unless, of course, we come up with a better solution).

Another important aspect of Design Patterns is the fact that they supply us with an abstraction over a problem, allowing for a better communication between software developers.

If one developer is trying to explain to his colleague all the steps he used to solve a particular problem, it may very well be a lengthy and confusing process. However if can reduce his explanations to something like, I’ve used a Flyweight here and an Observer there, then communication will be vastly improved.

And that’s why we need to learn them. Because we want to solve our problems in the most efficient ways and we want to be able to communicate with our peers and understand what they are saying.

Enough thoughts on the subject and let’s move on

Design patterns usually fall into three categories :

• Creational
• Structural
• Behavioural

Creational patterns
These are used to create objects for us. This means that instead of creating our own instances, we will request that objects are given to us, in the proper state, when we need them. This gives us an extra layer of flexibility, as the software itself may decide what kind of object to create for a given situation.

Structural patterns
As the applications grow in complexity, so our objects complexity starts to grow. We will eventually arrive to a point where objects will need to be grouped together to form some complex data structures. Managing those complex data structures manually every time we need them, my become a very complex task. The structural patterns try to abstract away that complexity, so that we can work with complex objects in a easier way.

Behavioural patterns
These patterns are responsible for the distribution of responsibilities amongst our objects, clearly defining how objects interact with each other,the flow of that communication and ensuring that the objects are loosely coupled.

So, How many patterns do exist out there ?

In one word , Many.

In this article we will only name 23, which are those referred in the GOF book, however there are many more. As technology and development languages evolves, new problems appear, and new ways to solve those problems are found. Eventually those new ways become so popular, well documented and tested that they become a design pattern by their own right.

The patterns mentioned in the GOF book are :

• Creational

  • Abstract factory
  • Builder
  • Factory Method
  • Prototype
  • Singleton

• Structural

  • Adapter
  • Bridge
  • Composite
  • Decorator
  • Facade
  • Flyweight
  • Proxy

• Behavioural

  • Chain of responsibility
  • Command
  • Interpreter
  • Iterator
  • Mediator
  • Memento
  • Observer
  • State
  • Strategy
  • Template method
  • Visitor

In my devlog, I will try to explain and document all the above patterns.

This is an ongoing project that I do in my free time, so stay tuned and comeback from time to time, to check out for new content.