Design Patterns Deconstructed: The Engineer's Guide to Reusable Solutions

Design patterns are reusable and effective solutions for common software design problems.

They provide paths to solutions for some of the most common object-oriented design conundrums. These are not theoretical concepts invented in a vacuum; they are solutions developed over time through trial and error, well-documented, and applicable to specific design problems.

Design patterns were first definitively described in the seminal book Design Patterns: Elements of Reusable Object-Oriented Software Design. Written by four software engineers (the "Gang of Four"), the book introduced 23 design patterns, divided into three distinct categories.

1. Creational Patterns

These patterns deal with object creation mechanisms, trying to create objects in a manner suitable to the situation.

• Abstract factory
• Builder
• Factory method
• Prototype
• Singleton

2. Structural Patterns

These patterns explain how to assemble objects and classes into larger structures while keeping these structures flexible and efficient.

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

3. Behavioral Patterns

These patterns are concerned with algorithms and the assignment of responsibilities between objects.

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

Design patterns help you create software that is resilient to change. However, it is crucial to understand that Design patterns are not algorithms or code.

A design pattern is an approach to thinking about software design. It incorporates the experience of developers who have solved similar problems, guided by fundamental principles. Usually, a pattern is expressed by a definition, a class diagram, and collected into a catalog.

Note: Design principles (like Encapsulation, Inheritance) and Design patterns are different. Principles are general guidelines, while patterns are specific design solutions aimed at solving common object-oriented problems.

Let’s dive into a few specific patterns to understand their practical application.

The Strategy Pattern

The Strategy pattern defines a family of algorithms, encapsulates each one, and makes them interchangeable. It lets the algorithm vary independently from the clients that use it.

According to Wikipedia:

“The strategy pattern (also known as the policy pattern) is a behavioral software design pattern that enables selecting an algorithm at runtime. Instead of implementing a single algorithm directly, code receives run-time instructions as to which in a family of algorithms to use.”

For example, a class that performs validation on incoming data may use the Strategy pattern to select a validation algorithm depending on the data type, source, or user choice. These factors are unknown until runtime.

This pattern relies heavily on the principle: If you have a choice, use composition (HAS-A) rather than inheritance (IS-A). Composition typically leads to a more flexible design.

The Adapter Pattern

The Adapter Pattern is used to convert the interface of a class into another interface that clients expect. The adapter lets classes work together that couldn’t otherwise because of incompatible interfaces.

The adapter sits in the middle of the client and the adaptee, delegating the client’s calls to the adaptee. The advantage is that you can add an adapter without modifying the adaptee code at all—you only need to modify the client to use the new adapter interface. This is essential when integrating 3rd-party vendor classes that you cannot modify.

The Observer Pattern

The Observer Design pattern acts as a publisher-subscriber relationship. Any object can send a request to subscribe to a publisher object. When the publisher receives the request, the requesting object becomes a subscriber.

The observer pattern defines a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically.

Observers are free to add or remove themselves from the list at any time. The subject (publisher) does not care who is listening; it simply maintains a list and notifies the objects on that list when necessary. This adheres to the Open-Closed Principle: code should be open for extension but closed for modification.

The Decorator Pattern

The Decorator pattern attaches additional responsibilities to an object dynamically.

Instead of creating a monolithic inheritance structure to add features, you wrap the object in a decorator class that adds the behavior. This allows for runtime modification of an object's capabilities.

The Iterator Pattern

We have many ways to store collections of objects: Arrays, ArrayLists, Lists, Dictionaries, or Sets. Writing code that traverses these collections can become messy if you have to handle each data structure differently.

The Iterator pattern provides a way to access the elements of an aggregate object sequentially without exposing its underlying representation.

Simply put, the Iterator Pattern pulls the iteration logic out into a separate iterator object. This iterator can then be used by different client codes to traverse various collection types (Array, ArrayList, etc.) uniformly.

The Factory Patterns

Factory allows us to decouple the process of creating objects from the clients that use those objects. This pattern defines an interface for creating an object but lets subclasses decide which classes to instantiate.

The Factory pattern encapsulates implementation details. The underlying implementation can change without any impact on the main usage code. It creates a robust system where the code is less coupled and easier to extend.

Conclusion

While design patterns are powerful, remember this crucial advice: You don’t have to use design patterns in a place where they are not needed.

Simplicity is key. Forcing a design pattern where it doesn't belong increases complexity and can make your system inefficient. Use patterns as a tool to solve specific problems, not as a checklist for every class you write.