Design Patterns

5 min readFeb 14, 2022

Design patterns are a fundamental part of software development, as they provide typical solutions to commonly recurring problems in software design.

Rather than providing specific pieces of software, design patterns are merely concepts that can be used to handle recurring themes in an optimized way.

Design Principle vs Design Pattern

In software engineering, design principle and design pattern are not the same. Design patterns are solutions while design principles are guidelines.

Design Principle

Design principles provide high-level guidelines to design better software applications. They do not provide implementation guidelines and are not bound to any programming language.

Design principles are core abstract principles that we are supposed to follow while designing software. They can be applied in any language, on any platform regardless of the state as long as we are within the permissible conditions.

Design Pattern

Design Patterns are solutions to real-world problems that pop up time and again, so instead of reinventing the wheel, we follow the design patterns that are well-proven, tested by others, and safe to follow. Now, design patterns are specific; there are terms and conditions only in which a design pattern can be applied.

Anti-Patterns

If there are good design patterns in software engineering that we should include in our application it’s obvious that there are bad patterns that we should avoid in our applications.

An Anti-Pattern is a literary form that describes a commonly occurring solution to a problem that generates decidedly negative consequences.

A good pattern in the wrong context is an anti-pattern.

Why do we need to know Design Patterns?

Design patterns are a toolkit of tried and tested solutions to common problems in software design.
Design Patterns provide easy-to-recognize and use OOP solutions to common problems.
Design patterns define a common language that you and your teammates can use to communicate more efficiently.
Design patterns can speed up the development process.

Classification of patterns

Creational — create new things

These patterns define how objects are created. If you need to create an object definitely you should use creational design patterns.

Structural — structure our code

These patterns define how objects relate to each other. They are easy to design by identifying a simple way to realize relationships between entities.

Behavioral — behaviors in our code

These patterns are designed depending on how one class communicates with others. They focus on the interaction between cooperated objects. In simple words, Behavioral Design Patterns are responsible for communication between objects.

The loose coupling is a key for the entire architecture. Coupling is the degree of interdependence between modules. Loose Coupling means, that modules should be independent as much as possible.

This pattern increases flexibility in caring the communication process.

Note: New design patterns are being developed every day and it’s not mandatory to know all of them, but at least you should be able to implement some of them.

We will consider the most commonly used design patterns in this article.

Creational Design Patterns

Constructor Pattern

The “constructor pattern”, as the name defines, is a class-based pattern that uses the constructors present in the class to create specific types of objects.

Constructors are used to initialize a newly created object. Constructors accept arguments so they can be used to set the values of the property and methods.

Module Pattern

Modules are used to encapsulate a group of methods for the following reasons:

Maintainability — avoid code duplication
Namespacing — avoid global variables and “namespace pollution”
Reusability — reuse your code in different places/projects

Factory Pattern

A factory pattern is an interface for creating an object but lets subclasses decide which class to instantiate. This pattern is one of the easiest to understand and implement. Factory pattern allows us to insert another layer/abstraction between instantiating an object.

Factory pattern allows us to:

Separate the object creation from its implementation. Essentially a factor wraps the carting of a new instance giving us more flexibility and control.
Create a different instance based on a condition.
Not expose the constructors of the object, preventing their modification.

Some terminology:

Concrete Object: The object returned from a Factory.
Concrete Creator: Class or method that calls the Creator (Factory method)
Creator: The Factory class. Declares a Factory method that will return the object requested from it (Concrete Object).

Abstract Factory Pattern

The Abstract Factory Pattern adds an abstraction layer over multiple other creational pattern implementations. You can think it’s a Factory that can return Factories or Builders, Prototypes, Singletons, or other design pattern implementations.

Builder Pattern

Builder Pattern can be used to simplify the construction of a complex object using different simple objects. This pattern lets you construct complex objects step by step.

Builder pattern allows us to:

Simplify the construction of a complex object.
Separate the construction and representation.
Use composition.
You can isolate complex construction code from the business logic of the product. (Single Responsibility Principle)
Different representations for the object that is constructed.

Prototype Pattern

The pattern lets you copy/clone existing instances rather than create the same instances from scratch. It reduces the need for creating subclasses.

You can use this pattern when your code shouldn’t depend on the concrete classes of objects that you need to copy.

Singleton Pattern

The pattern implementation is based on the if statement with the following condition: “Hey method, don’t create an object more than one time.”

Basically, we use this pattern when we want to make sure that we have only one class in your program that should have just a single instance available to all clients; for example, a single database object shared by different parts of the program.

Singleton Pattern allows us to:

Restrict instantiation of a class to a single object.
Remember the last time you used it and keeps the same instance across the application.

Structural Design Patterns

Decorator Pattern

Decorator Pattern lets you attach additional responsibility and modify functionality dynamically. Decorators provide a flexible alternative to subclassing for extending functionality using composition instead of inheritance.

Decorator Pattern is used in the Object Oriented and Functional paradigms.

In real word Decorator is Mechanic who update/decorate your car.

Adapter Pattern

Composition Pattern

We use composition design patterns when we need to work with a group of items or Trees. Due to this patter, you are able to create primitive and objects.

Facade Pattern

Facade Pattern it’s a wrapper for complex code (logic). This pattern makes our code cleaner and more reusable.

Behavioral Design Patterns

Flyweight Pattern

This pattern aims to minimize the use of memory in-app by sharing as much data as possible with related objects. Provides a mechanism by which you can avoid carting a large number of expensive objects and reuse existing instances to represent new objects.

Shared flyweight objects are immutable. The can’t be changed.

Strategy Pattern

This pattern lets you define a family of algorithms put each of them into a separate class, and make their objects interchangeable.

Command Patter

Command Pattern allows us to encapsulate operations that you want to do.