What are design patterns?

Design patterns are recurring solutions to software design problems that you find again and again in real-world application development. Design patterns are about design and interaction of objects, as well as providing a communication platform concerning elegant, reusable solutions to commonly encountered programming challenges.

Design patterns make it easier to reuse successful designs and architectures.

In general, a pattern has four essential elements:

• Name – Naming a pattern immediately increases our design vocabulary. It allows design at a higher level of abstraction.
• Problem – This element explains the problem and its context. It might describe specific design problems such as how to represent algorithms as objects.
• Solution – The solution describes the elements that make up the design, their relationships, responsibilities, and collaborations.
• Consequences – The consequences are the results and trade-offs of applying the pattern.

Why design patterns?

A design pattern systematically names, explains, and evaluates an important and recurring design in object-oriented systems. Design patterns capture design experience in a form that people can use effectively and make it easier to reuse successful designs and architectures. Expressing proven techniques as design patterns makes them more accessible to developers of new systems.

Design patterns help you choose design alternatives that make a system reusable and avoid alternatives that compromise reusability. They can even improve the documentation and maintenance of existing systems by furnishing an explicit specification of class and object interactions and their underlying intent.

Benefits

Experienced programmers do not to solve every problem from first principles. Instead they reuse solutions that have worked for them in past and when they find a good solution, they use it again and again. Consequently, we find recurring patterns of classes and communicating objects in many object-oriented systems

Design patterns have two major benefits. First, they provide a way to solve issues related to software development using a proven solution which facilitates the development of highly cohesive modules with minimal coupling. They isolate the variability that may exist in the system requirements, making the overall system easier to understand and maintain.

Second, they make communication between designers more efficient. Software professionals can immediately picture the high-level design in their heads when they refer the name of the pattern used to solve a particular issue when discussing system design.

Using design patterns in UML

How does a pattern relate to the UML?

The patterns that we encounter need to be captured and documented in a sufficiently descriptive manner so that they can be referred to for future use. UML provides the perfect tools to do just this.

The class diagram in UML can be used to capture the patterns identified in a system. In addition, UML has a sufficiently extensive and expressive vocabulary to capture the details of patterns. Building on this background we will see how to use well-known patterns to make application design a lot easier.

To sum up, a pattern should have the following characteristics:

• Useful Solution
• Reusable
• Contextual

Pattern forms

To give you a head start, design patterns can be provided in two forms:

• Structural – Structural code uses type names as defined in the pattern definition and UML diagrams.
• Real-world – Real-world code provides real-world programming situations where you may use the patterns.

The Gang of Four (GOF) patterns are generally considered the foundation for all other patterns. They are categorised into three groups:

Creational Patterns
Creational class patterns defer some part of object creation to subclasses, while Creational object patterns defer to another object.

• Abstract Factory – Creates an instance of several families of classes
• Builder – Separates object construction from its representation
• Factory Method – Creates an instance of several derived classes
• Prototype – A fully initialised instance to be copied or cloned
• Singleton – A class of which only a single instance can exist

Structural Patterns
The Structural class patterns use inheritance to compose classes, while the Structural object patterns describe ways to assemble objects.

• Adapter – Match interfaces of different classes
• Bridge – Separates an object’s interface from its implementation
• Composite – A tree structure of simple and composite objects
• Decorator – Add responsibilities to objects dynamically
• Façade – A single class that represents an entire subsystem
• Flyweight – A fine-grained instance used for efficient sharing
• Proxy – An object representing another object

Behavioural Patterns
The Behavioural class patterns use inheritance to describe algorithms and flow of control, whereas the Behavioural object patterns describe how a group of objects co-operate to perform a task that no single object can carry out alone.

• Chain of Responsibility – A way of passing a request between a chain of objects
• Command – Encapsulate a command request as an object
• Interpreter – A way to include language elements in a program
• Iterator – Sequentially access the elements of a collection
• Mediator – Defines simplified communication between classes
• Memento – Capture and restore an object’s internal state
• Observer – A way of notifying change to a number of classes
• State – Alter an object’s behaviour when its state changes

---

Saif Ikram is a Consultant for Genisys Software and an Associate Member of WWISA. He has been involved in designing several .NET projects and is currently working as a consultant at the Royal Bank of Scotland.