Design Patterns Cheatsheet

1. Introduction

Design patterns are reusable solutions to common software design problems. They provide a way to describe and document software architectures, as well as a common vocabulary for developers to communicate about software design.

There are several types of design patterns, including creational, structural, and behavioral patterns.

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

Structural patterns deal with object composition, creating relationships between objects to form larger structures.

Behavioral patterns focus on communication between objects, what goes on between objects and how they operate together.

2. Creational patterns

2.1 Singleton

The Singleton design pattern is used to ensure that a class has only one instance, and to provide a global access point to that instance.

Fig. 1: Singleton UML.

2.2 Factory

Provides a way to create objects without specifying the exact class of object that will be created. Has a method that creates objects of a specific type. The method takes the type of object to be created as an argument and returns a new object of that type.

Fig. 2: Factory UML.

2.3 Abstract Factory

Provides an interface for creating families of related or dependent objects without specifying their concrete classes.

Fig. 3: Abstract Factory UML.

2.4 Builder

Allows for the creation of complex objects in a step-by-step manner. It separates the construction of an object from its representation, allowing for different representations to be created.

Fig. 4: Builder UML.

2.5 Prototype

Allows for the creation of new objects by copying existing objects, rather than creating new objects from scratch.

Fig. 5: Prototype UML.

3. Structural patterns

3.1 Adapter

Allows two incompatible interfaces to work together by wrapping an adapter class around one of the interfaces. This adapter class converts the interface of the adapted class into the interface that the client is expecting.

Fig. 6: Adapter UML.

3.2 Bridge

Allows for the separation of abstraction and implementation, so that the two can vary independently.

Fig. 7: Bridge UML.

3.3 Composite

Allows objects to be treated as a single unit. It is used to compose objects into tree structures, and to create complex objects from simpler ones.

Fig. 8: Composite UML.

3.4 Decorator

Allows for the dynamic addition of new behavior to an existing object without changing its structure.

Fig. 9: Decorator UML.

3.5 Facade

Provides a simplified interface to a complex system.

Fig. 10: Facade UML.

3.6 Flyweight

Aims to minimize the use of memory by sharing common data among objects. This is done by creating a shared object that can be used by multiple objects, rather than each object having its own separate instance of the data.

Fig. 11: Flyweight UML.

3.7 Proxy

Provides an intermediary object between a client and a real subject.

The proxy pattern can be used to:

Fig. 12: Proxy UML.

4. Behavioral patterns

4.1 Chain of Responsibility

Allows an object to send a request to a chain of objects in order to handle the request.

Fig. 13: Chain of Responsibility UML.

4.2 Command

Allows for the encapsulation of a request as an object, which can then be passed to a receiver to be executed.

Fig. 14: Command UML.

4.3 Iterator

Allows clients to access elements of an aggregate object sequentially without exposing the object’s underlying representation.

Fig. 15: Iterator UML.

4.4 Mediator

Allows multiple objects to communicate with each other without knowing the details of their implementation.

Fig. 16: Mediator UML.

4.5 Observer

Allows an object (the subject) to notify a set of objects (the observers) when its state changes. The observer pattern is also known as the publish-subscribe pattern.

Fig. 17: Observer UML.

4.6 Strategy

Allows an object to change its behavior or strategy at runtime by switching to a different strategy object.

Fig. 18: Strategy UML.

4.7 Template Method

Defines the steps of an algorithm and allows subclasses to override certain steps, while still preserving the overall structure of the algorithm.

Fig. 19: Template Method UML.
Exit mobile version