Every design has a pattern and everything has a template, whether it be a cup, house, or dress. No one would consider attaching a cup’s handle to the inside – apart from novelty item man­u­fac­tur­ers. It has simply been proven that these com­pon­ents should be attached to the outside for practical purposes. If you are taking a pottery class and want to make a pot with handles, you already know what the basic shape should be. It is stored in your head as a design pattern, in a manner of speaking.

The same general idea applies to computer pro­gram­ming. Certain pro­ced­ures are repeated fre­quently, so it was no great leap to think of creating something like pattern templates. In our guide, we will show you how these design patterns can simplify pro­gram­ming.

What are design patterns?

The term ‘design pattern’ was ori­gin­ally coined by the American architect Chris­toph­er Alexander who created a col­lec­tion of reusable patterns. His plan was to involve future users of the struc­tures in the design process. This idea was then adopted by a number of computer sci­ent­ists. Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides (sometimes referred to as the Gang of Four or GoF) helped software patterns break through and gain ac­cept­ance with their book ‘Design Patterns – Elements of Reusable Object-Oriented Software’ in 1994.

Image: Applying design patterns
This sim­pli­fied diagram shows a software de­vel­op­ment procedure in which five different design patterns are tested to see whether they are suitable for solving the pro­gram­ming task.

So, what exactly are design patterns? Let us continue using our previous example. The same basic elements will always be needed for a cup: the bottom, sides, and a handle. This applies to all cups whether they be coffee, espresso or teacups. Pro­gram­ming is quite similar: Loops to be executed are always linked to start and end para­met­ers. Con­di­tions always require that op­er­a­tions be defined for what to do when they are met and what to do when they are not. Cal­cu­la­tions always output the results for the com­bin­a­tion of variables and so on. From many different pro­gram­ming steps, a program sequence can be created which always has the same steps for specific tasks. A design pattern is a de­scrip­tion of how to solve a problem.

Below, you will find a simple example of a software pattern, in this case, a factory pattern:

class Cup
{
    private $cupMake;
    private $cupModel;
    public function __construct($make, $model)
    {
        $this->cupMake = $make;
        $this->cupModel = $model;
    }
    public function getMakeAndModel()
    {
        return $this->cupMake . ' ' . $this->cupModel;
    }
}
class CupMaking
{
    public static function create($make, $model)
    {
        return new Cup($make, $model);
    }
}
$espresso = CupMaking::create('cup', 'espresso'); // Object is created
print_r($espresso->getMakeAndModel()); // Outputs ‘cup espresso’

The same applies to larger contexts and processes that are fre­quently used to solve specific tasks in program sequences. This code example can be extended as needed, even to be used in other in­dus­tries with com­pletely different products and processes. Needless to say, it is only one building block in a more extensive piece of software. In other words, design patterns should be con­sidered templates that have already been proven to work in practice.

What are the different types of design patterns?

The different types of design patterns reflect the basic ap­plic­a­tions of the software patterns compiled in each case.

Struc­tur­al patterns

Struc­tur­al patterns are ready-made templates for re­la­tion­ships between classes. The aim is to achieve an ab­strac­tion that can also com­mu­nic­ate with other solutions – the keyword here is interface pro­gram­ming.

Be­ha­vi­our­al patterns

Be­ha­vi­our­al patterns are used to model the software’s behavior. These patterns simplify complex processes for con­trolling and mon­it­or­ing. For this, you can choose between al­gorithms and object re­spons­ib­il­it­ies.

Cre­ation­al patterns

Cre­ation­al patterns are used to create objects which can simplify process design for specific instances. This works re­gard­less of how the in­di­vidu­al objects are created and rep­res­en­ted in the software.

Over time, ad­di­tion­al types of design patterns have been in­tro­duced that do not fit into any of the three cat­egor­ies described above. This includes patterns for object-re­la­tion­al mapping to store objects and their re­la­tion­ships in a re­la­tion­al database.

The pros and cons of using design patterns

Ad­vant­ages

The option to use tried and tested solutions can save you time and money. De­vel­op­ment teams do not have to con­stantly reinvent the wheel to solve subtasks in a program procedure that has already been solved multiple times before. The in­di­vidu­al patterns are usually named using common design vocab­u­lary. This sim­pli­fies dis­cus­sions between de­velopers as well as com­mu­nic­a­tion with the user of the future solution. The software’s doc­u­ment­a­tion is also sim­pli­fied if you use building blocks that have already been doc­u­mented. These ad­vant­ages also hold true for the main­ten­ance and further de­vel­op­ment of a program.

Dis­ad­vant­ages

Using design patterns requires extensive knowledge. Having design patterns available can also lead to people believing that ap­par­ently all problems can be solved using existing design patterns. In short, this can limit cre­ativ­ity and the desire to find new (better) solutions.

What are the common design patterns?

There are more than seventy design patterns across various cat­egor­ies. The following are some important software patterns:

Cre­ation­al patterns

  • Builder pattern: This cre­ation­al pattern separates the de­vel­op­ment of a (complex) object from its rep­res­ent­a­tion.
  • Factory pattern: This cre­ation­al pattern creates an object by calling a method instead of a con­struct­or.
  • Singleton pattern: This cre­ation­al pattern ensures that a class only has one object and provides global access to it.

Struc­tur­al patterns

  • Composite pattern: This struc­tur­al pattern is specially designed to handle dynamic struc­tures, such as for file or­gan­isa­tion or data com­pres­sion.
  • Decorator pattern: This pattern in­teg­rates ad­di­tion­al functions or re­spons­ib­il­it­ies into existing classes.
  • Facade pattern: This pattern provides an interface for other systems or sub-systems.

Be­ha­vi­or­al patterns

  • Observer pattern: This pattern passes on modi­fic­a­tions made to an object to struc­tures that depend on the original object.
  • Strategy pattern: This pattern defines a family of in­ter­change­able al­gorithms.
  • Visitor pattern: This pattern isolates ex­ecut­able op­er­a­tions so that new op­er­a­tions can be performed without changing the relevant classes.
Summary

Design patterns are ready-made patterns that solve specific problems by relying on tried and tested concepts. They build on real existing software designs and involve the user of the future solution in the design process. For the moment, design patterns are not re­stric­ted to any one pro­gram­ming language. This makes them uni­ver­sally ap­plic­able.

Go to Main Menu