What is a Design Pattern?

Design patterns provide proven solutions for typical challenges in software design. They abstract recurring tasks or problems and enable developers to concentrate on the essentials of the design – without getting lost in technical details. Because they can be reused, they save time and effort in design and implementation. At the same time, they create flexibility through clearly defined interfaces and rules for adaptations and extensions. Their modular structure reduces the coupling between components, thus facilitating maintenance. In addition, design patterns promote communication within the team by creating a common understanding of terms.

Types and categories of design patterns

There are different types or categories of design patterns. According to the so-called Gang of Four [1], there are three basic categories, each addressing different aspects of software design:

Creational patterns:

These design patterns support the controlled and flexible creation of objects. They decouple the creation process from the specific implementation, thus offering more customisation options. The aim is to create objects in such a way that they fit well into the respective application context. Typical examples are:

• Singleton: Ensures that a class has only one instance and provides a global point of access.
• Factory Method: Defines an interface for object creation, while the concrete instantiation is left to subclasses.
• Abstract Factory: Creates families of related objects without knowing their specific classes.
• Builder: Separates the construction of complex objects from their representation, so that different variants of the same object can be created.
• Prototype: Creates new objects by copying an existing prototype.

Structural patterns:

Structural patterns help to combine classes and objects into larger, stable structures. They define clear relationships between components and make it possible to extend functionality without changing the internal structure. Well-known examples are:

• Adapter: Adapts the interface of one class to another to make incompatible classes work together.
• Bridge: Separates abstraction and implementation so that both can be changed independently.
• Composite: Allows objects to be grouped into tree structures in order to handle part-whole hierarchies consistently.
• Decorator: Adds additional functionality to an object at runtime without changing its structure.
• Facade: Provides a simplified interface to a complex subsystem.
• Flyweight: Reduces memory consumption of large object sets by sharing common data.
• Proxy: Provides a placeholder object that controls access to another object.

Behavioural Patterns:

These design patterns focus on the interaction and communication between objects. They describe how objects work together and share responsibility to accomplish complex tasks. Common patterns in this group include:

• Observer: Ensures that dependent objects are automatically notified when the state of a subject changes.
• Strategy: Encapsulates a family of algorithms that can be used interchangeably.
• Command: Packages requests as objects to execute, log or reverse them later.
• State: Enables an object to dynamically change its behaviour when state changes occur.
• Template Method: Defines the basic structure of an algorithm and allows subclasses to override certain steps.
• Mediator: Encapsulates communication between objects, thus reducing direct dependencies.
• Chain of Responsibility: Passes a request through a chain of handlers until one of them handles it.
• Interpreter: Implements a language and processes expressions through a common interpretation model.
• Visitor: Separates algorithms from the data structures on which they operate and allows new operations without changing existing classes.

In addition to these ‘classic’ categories – creation patterns, structure patterns and behaviour patterns – there are other pattern groups that address specific challenges:

Patterns for object-relational mapping (Object-Relational Mapping Patterns):

These design patterns solve typical problems when mapping object-oriented structures to relational databases. They help to bridge inconsistencies between the object model and the database model. Frequently used patterns are:

• Data Mapper: Completely separates the business logic from the database access by using a separate component for data transfer.
• Active Record: Combines data and database operations in one object – each object represents one database row.
• Identity Map: Ensures that each database object exists only once in memory to avoid multiple instances.
• Unit of Work: Bundles changes to objects and coordinates their storage in the database as a transaction.

Message transmission patterns (messaging patterns):

These design patterns concern the communication between distributed systems or components via messages. They define how information can be transmitted reliably, efficiently and decoupled. Central patterns are:

• Message Queue: Enables asynchronous communication by buffering messages for later processing.
• Publish/Subscribe: Sends messages to all interested subscribers without the sender and receiver having to know each other.
• Message Router: Forwards messages to the correct recipient or path based on certain rules.
• Message Filter: Filters incoming messages based on defined criteria to sort out irrelevant information.

Other patterns:

There are also design patterns that cannot be clearly assigned to any of the classic categories, but are nevertheless widespread and useful. These include:

• Service Locator: Provides a central location to provide objects or services without direct dependency on their implementation.
• Dependency Injection: Transfers responsibility for providing dependencies to external components (e.g. frameworks).
• Null Object: Uses an object with neutral behaviour instead of null to avoid null checks.
• Lazy Initialization: Delays the creation of an object until the point in time when it is actually needed.

These types or categories provide a structured basis for designing robust, flexible and maintainable software systems – regardless of the programming language or application context.

Advantages and disadvantages of design patterns

The application of design patterns in software projects brings a number of advantages. One of the biggest plus points is reusability: design patterns provide tried and tested solutions for common problems, thereby saving time and development effort. At the same time, they promote code maintainability by supporting modularity and decoupling – this makes the code more comprehensible, easier to modify and easier to maintain in the long term.

Another advantage is the increased flexibility and expandability. Thanks to clearly defined interfaces and structured architectures, new functionalities can be integrated more easily and existing components can be adapted to changing requirements. In addition, design patterns improve communication within the team, as they create a common vocabulary that all participants can refer to.

Last but not least, design patterns help to improve software quality. Their application leads to more robust, reliable systems because they are based on proven concepts. They contain the collective expert knowledge of the software development community – experiences and solutions that have proven themselves in many projects and from which new developments can benefit directly.

Despite their many advantages, design patterns can also have certain disadvantages. If a pattern is used without consideration or excessively, it can lead to unnecessary complexity in the system and even impair maintainability – especially if the chosen pattern does not fit well with the actual problem.

Another aspect is the learning curve: it takes time, experience and a good understanding to apply design patterns sensibly and correctly. Without the necessary background knowledge, there is a risk of using patterns mechanically without really understanding their purpose or limitations.

In some situations, it may also be more efficient to develop a specific solution tailored to the problem at hand rather than to adapt a general pattern at great expense. If an unsuitable pattern is chosen, this can, in the worst case, even have a negative impact on the performance of the system.

Therefore, when applying design patterns, it is crucial to use them consciously and in a way that is appropriate to the situation in order to actually take advantage of their benefits without creating new problems.

Tips for applying design patterns

There are some not-so-obvious but very valuable tips for working with design patterns that go beyond the usual ‘learn the GoF patterns’ and ‘use design patterns appropriately’. Here are a few insights that you usually only gain with a little project experience:

1. design patterns are tools, not goals

Many developers (especially at the beginning) are obsessed with trying to incorporate a pattern, even when the problem doesn’t require it. It’s better to develop the code first and then refactor it. Often it’s only in the second or third iteration that the right pattern emerges.

2. recognising patterns is more important than writing them

In real projects, it’s often about recognising existing patterns in the design of others – for example, when debugging, refactoring or reviewing. Those who can do this will understand more quickly how a system works. This saves time and prevents errors.

3. combinations are often the reality

In practice, patterns rarely occur in isolation. Instead, they often interact with each other – e.g. an observer that is coordinated via a mediator or a builder that is used in a factory. Those who can combine patterns can design more flexible architectures.

4. it pays to know variants and modifications

Many patterns exist not only in the ‘GoF version’, but in countless variants. For example, there are different singleton implementations with lazy loading, thread safety, etc. Understanding why these variants exist helps in using them correctly.

5. design patterns are not a substitute for religion

A well-chosen, simple if-else block is sometimes better than a complicated strategy pattern. Patterns must not be allowed to sacrifice readability or simplicity – they only make sense if they really make life easier.

6. document project-specific ‘patterns’

In large code bases, recurring structures often arise that are not found in books – for example, typical event handling or caching behaviour. These team-internal patterns should be documented and named as ‘custom patterns’. This improves communication and onboarding enormously.

7. patterns are excellent discussion tools

A sentence like ‘This looks like a Decorator, doesn’t it?’ is extremely helpful, especially in code reviews or architecture meetings. Even if you decide against it in the end, the term creates a common basis for discussing alternatives.

8. patterns help with refactoring – not only with design

Many patterns are ideal for organising confusing or evolved code. Instead of rewriting everything, you can use the targeted application of patterns such as state, strategy or command to clarify structures – evolutionary design for refactoring instead of a big bang approach.

Questions from the field

Here are some questions and answers from the field:

Impulse to discuss:

Which supposedly tried and tested practices in an organisation could in fact have long since become anti-patterns – and why is no one questioning them?

Notes:

[1] Gang of Four (GoF): The name given to the quartet of authors Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides who, with their book Design Patterns: Elements of Reusable Object-Oriented Software, published in 1994, contributed significantly to the establishment of design patterns in object-oriented software development. The work describes 23 fundamental design patterns, divided into creation, structure and behaviour patterns, and is still considered a standard reference in software architecture today.

Here you will find a video about the design patterns of the Gang of Four.

If you like the article or would like to discuss it, please feel free to share it in your network. And if you have any comments, please do not hesitate to send us a message.

And here you will find additional information from our Smartpedia section:

t2informatik develops and modernises software as a service provider. Click here to learn more.