Introduction to software design patterns

As programmers we have probably noticed that we often solve the same problem in different ways. This can be a good thing at the beginning of our career: we experience different ways of approaching a problem and we can compare the pros and cons of our previous solutions, but as time goes by we like to go straight to the point, and apply the most scalable, most testable and most reusable solution. Of course not having to explain to every colleague how we solved the case is also desirable, but this is not solved by patterns (unless our colleague knows them too).

What are software design patterns?

Well, they are neither more nor less “standardized” ways of solving common design problems in software development.

The advantages of using patterns are obvious:

• They form a wide range of problems and solutions.
• Standardize the resolution of certain problems
• Condensed and simplified learning of best practices
• Provide a common vocabulary among developers
• Avoid “reinventing the wheel”

Books on design patterns

One of the first books that dealt with the topic of design patterns was the famous Design Patterns from Gang of FourErich Gamma, Richard Helm, Ralph Johnson and John Vlissides. With the passage of time, some of the patterns discussed are now considered as antipatterns.

A book to learn about patterns in a more enjoyable way is the Head First Design Patterns which I personally like quite a lot.

And if what we want is to learn how to refactor our code so that it takes advantage of the design patterns, it is the Refactoring to patterns by Joshua Kerievsky, in which the author provides us with information about each pattern:

• A theoretical explanation (including UML)
• A recipe to apply the pattern
• An example of refactorable code
• The application of the recipe on the previous code.

These are my three main books on patterns, but there is a lot of literature on the subject.

Types of patterns

According to the purpose of the pattern, they are classified into three types:

• Creative Patterns
• Structural Patterns
• Behavioral patterns.

Let's look at each of these types in detail.

Creative Patterns

As its name indicates, these patterns come to solve or facilitate the tasks of creation or instantiation of objects.

These patterns emphasize the encapsulation of the instantiation logic, hiding the concrete details of each object and allowing us to work with abstractions.

Some of the best known creative patterns are:

• Factory: Decouple the creation logic from the business logic, preventing the client from knowing details of the instantiation of the objects on which it depends.
• Abstract Factory: It provides us with an interface that delegates the creation of a series of related objects without the need to specify which are the concrete implementations.
• Factory Method: It exposes a creation method, delegating to subclasses the implementation of this method.
• BuilderSeparates the creation of a complex object from its structure, so that the same construction process can be used to create different representations.

Structural patterns

Structural patterns help us define the way in which objects are composed.

The most common structural patterns are:

• AdapterIntermediate class: Helps us to define an intermediate class that allows two classes with different interfaces to communicate. This class acts as a mediator, making class A able to execute methods of class B without knowing details of its implementation. It is also known as Wrapper.
• DecoratorAllows you to add extra functionality to an object (decorate the object) without modifying the behavior of the other instances.
• Facade: A facade is an object that creates a simplified interface to deal with another more complex part of the code.

Behavioral patterns

Behavioral patterns help us define how objects interact with each other.

Some of the best known (to name a few) are:

• CommandThey are objects that encapsulate an action and the parameters they need to be executed.
• ObserverObjects are able to subscribe to a series of events that another object is going to emit, and will be alerted when this occurs.
• StrategyAllows the selection of the algorithm that executes a certain action at run time.
• Template Method: Specifies the skeleton of an algorithm, allowing subclasses to define how they implement the actual behavior.

Antipatterns

Not all employers are going to be good, there are so called "good" employers. anti-patterns, The "evil twins" that lead us to implement bad solutions.

It is also good to be aware of anti-patterns in order to detect a future headache in time.

Earlier we talked about the GoF (Gang of Four) book and how some patterns have come to be considered anti-patterns. A very clear example is the Singleton.

The Singleton pattern is a creational pattern, which helps us to have only one instance of a class. This is useful in cases such as objects that handle the connection to a database or other services, since it reduces memory usage by restricting the creation of more objects.

On the other hand, the pattern makes use of private and static methods, reduces the object almost to a global variable, makes testing difficult... The punctual use of singleton does not have to be bad in itself, but abuse can be fatal in the short term, so a good number of programmers consider it an anti-pattern.