Software Design Patterns Distilled

Software Design Patterns Distilled

Patterns are a toolkit of solutions to common problems in software design

·

6 min read

What is a Design Pattern?

A Design pattern is a solution to a problem in a context.

That’s not the most revealing definition, is it? But don’t worry, I am going to step through each of these parts, context, problem, and solution.

Context

The context is the situation in which the pattern applies. This should be a recurring situation.

Example: You have a collection of objects.

Problem

The problem refers to the goal you are trying to achieve in this context, but it also refers to any constraints that occur in the context.

Example: You need to step through the objects without exposing the collection’s implementation.

Solution

The solution is what you’re after: a general design that anyone can apply which resolves the goal and set of constraints.

Example: Encapsulate the iteration into a separate class.


Let’s think about this a bit... We need a problem, a solution, and a context:

Problem: How do I get to work on time?

Context: I’ve locked my keys in the car.

Solution: Break the window, get in the car, start the engine, and drive to work.

We have all the components of the definition: we have a problem, which includes the goal of getting to work, and the constraints of time, distance, and probably some other factors. We also have a context in which the keys to the car are inaccessible. And we have a solution that gets us to the keys and resolves both the time and distance constraints. We must have a pattern now! Right?

Moving forward!!

Design Patterns are further classified into 3 categories, which are as follows:

Creational Patterns

Creational patterns involve object instantiation and all provide a way to decouple a client from the objects it needs to instantiate.

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

Structural Patterns

Structural patterns let you compose classes or objects into larger structures.

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

Behavioral Patterns

Any pattern is a Behavioral Pattern that is concerned with how classes and objects interact and distribute responsibility.

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

Patterns are often classified by a second attribute: whether or not the pattern deals with classes or objects:

Class patterns

Class patterns describe how relationships between classes are defined via inheritance. Relationships in class patterns are established at compile time.

Object patterns

Object patterns describe relationships between objects and are primarily defined by composition. Relationships in object patterns are typically created at runtime and
are more dynamic and flexible.

Now you have good theoretical knowledge of Design Patterns. I have covered the 23 most used design patterns in this guide. It will be fun to learn all the tricks used in design patterns to solve a specific problem. So, let's jump into each design pattern and see its intent and implementation.

Creational Design Patterns

#1 Factory Method

The Factory Method Pattern defines an interface for creating an object but lets subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses.

Source Code

#2 Abstract Factory

The Abstract Factory Pattern provides an interface for creating families of related or dependent objects without specifying their concrete classes.

Source Code

#3 Builder

Builder is a creational design pattern that lets you construct complex objects step by step. The pattern allows you to produce different types and representations of an object using the same construction code.

Source Code

#4 Prototype

The prototype is a creational design pattern that lets you copy existing objects without making your code dependent on their classes.

Source Code

#5 Singleton

The Singleton Pattern ensures a class has only one instance, and provides a global point of access to it.

Source Code


Structural Design Patterns

#6 Adapter

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

Source Code

#7 Bridge

The bridge is a structural design pattern that lets you split a large class or a set of closely related classes into two separate hierarchies abstraction and implementation which can be developed independently of each other.

Source Code

#8 Composite

The Composite Pattern allows you to compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly.

Source Code

#9 Decorator

The Decorator Pattern attaches additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality.

Source Code

#10 Facade

The Facade Pattern provides a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use.

Source Code

#11 Flyweight

Flyweight is a structural design pattern that lets you fit more objects into the available amount of RAM by sharing common parts of the state between multiple objects instead of keeping all of the data in each object.

Source Code

#12 Proxy

The Proxy Pattern provides a surrogate or placeholder for another object to control access to it.

Source Code


Behavioral Design Patterns

#13 Chain of Responsibility

A chain of Responsibility is a behavioral design pattern that lets you pass requests along a chain of handlers. Upon receiving a request, each handler decides either to process the request or to pass it to the next handler in the chain.

Source Code

#14 Command

The Command Pattern encapsulates a request as an object, thereby letting you parameterize other objects with different requests, queue or log requests, and support undoable operations.

The Command Pattern allows you to decouple the requester of an action from the object that actually performs the action.

Source Code

#15 Iterator

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

Source Code

#16 Mediator

The mediator is a behavioral design pattern that lets you reduce chaotic dependencies between objects. The pattern restricts direct communications between the objects and forces them to collaborate only via a mediator object.

Source Code

#17 Memento

Memento is a behavioral design pattern that lets you save and restore the previous state of an object without revealing the details of its implementation.

Source Code

#18 Observer

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

Source Code

#19 State

The State Pattern allows an object to alter its behavior when its internal state changes. The object will appear to change its class.

Source Code

#20 Strategy

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

Source Code

#21 Template Method

The Template Method Pattern defines the skeleton of an algorithm in a method, deferring some steps to subclasses. The Template Method lets subclasses redefine certain steps of an algorithm without changing the algorithm’s structure.

Source Code

#22 Visitor

The visitor is a behavioral design pattern that lets you separate algorithms from the objects on which they operate.

Source Code

#23 Null Object

The intent of a Null Object is to encapsulate the absence of an object by providing a substitutable alternative that offers suitable default do nothing behavior. In short, a design where "nothing will come of nothing"

Source Code


Thanks for reading

I really hope you like reading it

Follow me: https://www.linkedin.com/in/imazizbohra/