Software design patterns are important tools developers, providing proven

solutions to common problems encountered during software development

What are Design Patterns?

Reusable solutions for typical software design challenges are known as
design patterns. Expert object-oriented software engineers use these best
practices to write more structured, manageable, and scalable code. Design
patterns provide a standard terminology and are specific to particular
scenarios and problems. Design patterns are not finished code but templates
or blueprints only.

Key Characteristics of Design Patterns

 Reusability: Patterns can be applied to different projects and problems,
saving time and effort in solving similar issues.
 Standardization: They provide a shared language and understanding
among developers, helping in communication and collaboration.
 Efficiency: By using these popular patterns, developers can avoid finding
the solution to same recurring problems, which leads to faster
development.
 Flexibility: Patterns are abstract solutions/templates that can be adapted
to fit various scenarios and requirements.

Types of Software Design Patterns

There are three types of Design Patterns:
 Creational Design Pattern
 Structural Design Pattern
 Behavioral Design Pattern

1. Creational Design Patterns

Creational Design Patterns focus on the process of object creation or
problems related to object creation. They help in making a system
independent of how its objects are created, composed and represented.
Types of Creational Design Patterns:
 Factory Method Design Pattern
o This pattern is typically helpful when it's necessary to separate
the construction of an object from its implementation.
o With the use of this design pattern, objects can be produced
without having to define the exact class of object to be created.
 Abstract Factory Method Design Pattern
o Abstract Factory pattern is almost similar to Factory Pattern and
is considered as another layer of abstraction over factory pattern.
o Abstract Factory patterns work around a super-factory which
creates other factories.
 Singleton Method Design Pattern
o Of all, the Singleton Design pattern is the most straightforward to
understand.
o It guarantees that a class has just one instance and offers a way
to access it globally.
 Prototype Method Design Pattern
o Prototype allows us to hide the complexity of making new
instances from the client.
o The concept is to copy an existing object rather than creating a
new instance from scratch, something that may include costly
operations.
 Builder Method Design Pattern
o To “Separate the construction of a complex object from its
representation so that the same construction process can create
different representations.” Builder pattern is used
o It helps in constructing a complex object step by step and the
final step will return the object.
2. Structural Design Patterns
Structural Design Patterns solves problems related to how classes and
objects are composed/assembled to form larger structures which are efficient
and flexible in nature. Structural class patterns use inheritance to compose
interfaces or implementations.

Types of Structural Design Patterns:

 Adapter Method Design Pattern
o The adapter pattern convert the interface of a class into another
interface clients expect.
o Adapter lets classes work together that couldn’t otherwise
because of incompatible interfaces.
 Bridge Method Design Pattern
o The bridge pattern allows the Abstraction and the
Implementation to be developed independently.
o The client code can access only the Abstraction part without
being concerned about the Implementation part.
 Composite Method Design Pattern
o As a partitioning design pattern, the composite pattern
characterizes a collection of items that are handled the same
way as a single instance of the same type of object.
o The intent of a composite is to “compose” objects into tree
structures to represent part-whole hierarchies.
 Decorator Method Design Pattern
 o It allows us to dynamically add functionality and behavior to an
object without affecting the behavior of other existing objects
within the same class.
o We use inheritance to extend the behavior of the class. This
takes place at compile-time, and all the instances of that class
get the extended behavior.
 Facade Method Design Pattern
o Facade Method Design Pattern provides a unified interface to a
set of interfaces in a subsystem.
o Facade defines a high-level interface that makes the subsystem
easier to use.
 Flyweight Method Design Pattern
o This pattern provides ways to decrease object count thus
improving application required objects structure.
o Flyweight pattern is used when we need to create a large
number of similar objects.
 Proxy Method Design Pattern
o Proxy means ‘in place of’, representing’ or ‘in place of’ or ‘on
behalf of’ are literal meanings of proxy and that directly explains
Proxy Design Pattern.
o Proxies are also called surrogates, handles, and wrappers. They
are closely related in structure, but not purpose, to Adapters and
Decorators.
3. Behavioral Design Patterns
Behavioral Patterns are concerned with algorithms and the assignment of
responsibilities between objects. Behavioral patterns describe not just
patterns of objects or classes but also the patterns of communication
between them. These patterns characterize complex control flow that’s
difficult to follow at run-time.
Types of Behavioral Design Patterns:
 Chain Of Responsibility Method Design Pattern
o Chain of responsibility pattern is used to achieve loose coupling
in software design where a request from the client is passed to a
chain of objects to process them.
o Later, the object in the chain will decide themselves who will be
processing the request and whether the request is required to be
sent to the next object in the chain or not.
 Command Method Design Pattern
o A behavioral design pattern called the Command Pattern
transforms a request into an independent object with all of the
information's request
o This object can be passed around, stored, and executed at a
later time.
 Interpreter Method Design Pattern
o Interpreter pattern is used to defines a grammatical
representation for a language and provides an interpreter to deal
with this grammar.
 Mediator Method Design Pattern
o It enables decoupling of objects by introducing a layer in
between so that the interaction between objects happen via the
layer.
 Memento Method Design Patterns
o It is used to return an object's state to its initial state.
 o You might wish to create checkpoints in your application and
return to them at a later time when it develops.
 Observer Method Design Pattern
o It establishes a one-to-many dependency between objects,
meaning that all of the dependents (observers) of the subject are
immediately updated and notified when the subject changes.
 State Method Design Pattern
o When an object modifies its behavior according to its internal
state, the state design pattern is applied.
o If we have to change the behavior of an object based on its
state, we can have a state variable in the Object and use the if-
else condition block to perform different actions based on the
state.
 Strategy Method Design Pattern
o It is possible to select an object's behavior at runtime by utilizing
the Strategy Design Pattern.
o Encapsulating a family of algorithms into distinct classes that
each implement a common interface is the foundation of the
Strategy pattern.
 Template Method Design Pattern
o The template method design pattern defines an algorithm as a
collection of skeleton operations, with the child classes handling
the implementation of the specifics.
o The parent class maintains the overall structure and flow of the
algorithm.
 Visitor Method Design Pattern
o It is used when we have to perform an operation on a group of
similar kind of Objects. With the help of visitor pattern, we can
move the operational logic from the objects to another class.

Adapter Design Pattern

Adapter Design Pattern | GeeksforGeeks

One structural design pattern that enables the usage of an existing class’s
interface as an additional interface is the adapter design pattern. To make
two incompatible interfaces function together, it serves as a bridge. This
pattern involves a single class, the adapter, responsible for joining
functionalities of independent or incompatible interfaces.
What is Adapter Design Pattern?
Two incompatible interfaces or systems can cooperate by using the adapter
design pattern, a structural design pattern. Because of incompatible
interfaces, it serves as a bridge between two classes that would not
otherwise be able to communicate. The adapter approach is very helpful
when attempting to incorporate third-party libraries or legacy code into a new
system.
Real-World Example of Adapter Design Pattern
Let’s understand this concept using a simple example:
Suppose you have two buddies, one of them speaks French exclusively and
the other English exclusively. The language barrier prevents them from
communicating the way you want them to.
 You act as an adapter, translating messages between them. Your role
allows the English speaker to convey messages to you, and you convert
those messages into French for the other person.
 In this way, despite the language difference, your adaptation enables
smooth communication between your friends.
 This role you play is similar to the Adapter design pattern, bridging the
gap between incompatible interfaces.
Components of Adapter Design Pattern
Below are the components of adapter design pattern:
 Target Interface: Defines the interface expected by the client. It
represents the set of operations that the client code can use. It’s the
common interface that the client code interacts with.
 Adaptee: The existing class or system with an incompatible interface that
needs to be integrated into the new system. It’s the class or system that
the client code cannot directly use due to interface mismatches.
 Adapter: A class that implements the target interface and internally uses
an instance of the adaptee to make it compatible with the target interface.
 It acts as a bridge, adapting the interface of the adaptee to match the
target interface.
 Client: The code that uses the target interface to interact with objects. It
remains unaware of the specific implementation details of the adaptee
and the adapter. It’s the code that benefits from the integration of the
adaptee into the system through the adapter.
Different implementations of Adapter Design Pattern
The Adapter Design Pattern can be applied in various ways depending on
the programming language and the specific context. Here are the primary
implementations:
1. Class Adapter (Inheritance-based)
 In this approach, the adapter class inherits from both the target
interface (the one the client expects) and the adaptee (the existing
class needing adaptation).
 Programming languages that allow multiple inheritance, like C++, are
more likely to use this technique.
 However, in languages like Java and C#, which do not support multiple
inheritance, this approach is less frequently used.
2. Object Adapter (Composition-based)
 The object adapter employs composition instead of inheritance. In this
implementation, the adapter holds an instance of the adaptee and
implements the target interface.
 This approach is more flexible as it allows a single adapter to work with
multiple adaptees and does not require the complexities of inheritance.
 The object adapter is widely used in languages like Java and C#.
3. Two-way Adapter
 A two-way adapter can function as both a target and an adaptee,
depending on which interface is being invoked.
 This type of adapter is particularly useful when two systems need to
work together and require mutual adaptation.
4. Interface Adapter (Default Adapter)
 When only a few methods from an interface are necessary, an
interface adapter can be employed.
 This is especially useful in cases where the interface contains many
methods, and the adapter provides default implementations for those
that are not needed.
 This approach is often seen in languages like Java, where abstract
classes or default method implementations in interfaces simplify the
implementation process.
How Adapter Design Pattern works?
Below is how adapter design pattern works:
 Step 1: The client initiates a request by calling a method on the adapter
via the target interface.
 Step 2: The adapter maps or transforms the client’s request into a format
that the adaptee can understand using the adaptee’s interface.
 Step 3: The adaptee does the actual job based on the translated request
from the adapter.
 Step 4: The client receives the results of the call, remaining unaware of
the adapter’s presence or the specific details of the adaptee.

Command Design Pattern

The Command Design Pattern is a behavioral design pattern that turns a
request into a stand-alone object called a command. With the help of this
pattern, you can capture each component of a request, including the object
that owns the method, the parameters for the method, and the method itself.
By doing this, you can easily pass, queue, or log requests and support
operations like undo/redo.
What is the Command Design Pattern?
The Command Design Pattern is a behavioral design pattern that turns a
request into a stand-alone object called a command. With the help of this
pattern, you can capture each component of a request, including the object
that owns the method, the parameters for the method, and the method itself.
 The Command Pattern encapsulates a request as an object, allowing for
the separation of sender and receiver.
 Commands can be parameterized, meaning you can create different
commands with different parameters without changing the invoker.
 It decouples the sender from the receiver, providing flexibility and
extensibility.
 The pattern supports undoable operations by storing the state or reverse
commands.
Components of the Command Design Pattern
1. Command Interface
The Command Interface is like a rulebook that all command classes follow. It
declares a common method, execute(), ensuring that every concrete
command knows how to perform its specific action. It sets the standard for all
commands, making it easier for the remote control to manage and execute
diverse operations.
2. Concrete Command Classes
Concrete Command Classes are the specific commands, like turning on a TV
or adjusting the stereo volume. Each class encapsulates the details of a
particular action. These classes act as executable instructions that the
remote control can trigger without worrying about the small details.
3. Invoker (Remote Control)
The Invoker, often a remote control, is the one responsible for initiating
command execution. It holds a reference to a command but doesn’t delve
into the specifics of how each command works. It’s like a button that, when
pressed, makes things happen.
4. Receiver (Devices)
The Receiver is the device that knows how to perform the actual operation
associated with a command. It could be a TV, stereo, or any other device.
Receivers understand the specific tasks mentioned in commands.
 If a command says, “turn on,” the Receiver (device) knows precisely how
to execute that action.
 The Receiver-Command relationship separates responsibilities, making it
easy to add new devices or commands without messing with existing
functionality.
How to implement Command Design Pattern?
Below are the simple steps to implement the Command Design Pattern:
1. Create the Command Interface: Define an interface or abstract class
that declares the execute() method. This method will be called to carry
out the action.
2. Create Concrete Command Classes: Implement the command interface
in multiple classes. Each class will represent a different command and will
call the appropriate method on the receiver to perform the specific action.
3. Define the Receiver Class: This class contains the actual logic that
needs to be executed. The command objects will call methods on this
receiver to perform actions.
4. Create the Invoker Class: The invoker triggers the
command’s execute() method but doesn’t know the details of the
operation. It simply knows that it needs to call the command.
5. Client Uses the Command: The client creates the concrete command
objects and associates them with the receiver. It then assigns commands
to the invoker, which will call them when needed.
Command Design Pattern example
Problem Statement:
Imagine you are tasked with designing a remote control system for various
electronic devices in a smart home. The devices include a TV, a stereo, and
 potentially other appliances. The goal is to create a flexible remote control
that can handle different types of commands for each device, such as turning
devices on/off, adjusting settings, or changing channels.

Strategy Design Pattern



The Strategy Design Pattern defines a family of algorithms, encapsulates each one,
and makes them interchangeable, allowing clients to switch algorithms dynamically
without altering the code structure.
What is the Strategy Design Pattern?
The Strategy Design Pattern is a behavioral design pattern that allows you to
define a family of algorithms or behaviors, put each of them in a separate
class, and make them interchangeable at runtime. This pattern is useful
when you want to dynamically change the behavior of a class without
modifying its code.
Characteristics of this design pattern
This pattern exhibits several key characteristics, such as:
 Defines a family of algorithms: The pattern allows you to encapsulate
multiple algorithms or behaviors into separate classes, known as
strategies.
 Encapsulates behaviors: Each strategy encapsulates a specific
behavior or algorithm, providing a clean and modular way to manage
different variations or implementations.
 Enables dynamic behavior switching: The pattern enables clients to
switch between different strategies at runtime, allowing for flexible and
dynamic behavior changes.
 Promotes object collaboration: The pattern encourages collaboration
between a context object and strategy objects, where the context
delegates the execution of a behavior to a strategy object.
Components of the Strategy Design Pattern

1. Context
A class or object known as the Context assigns the task to a strategy object
and contains a reference to it.
 It serves as an intermediary between the client and the strategy, offering
an integrated approach for task execution without exposing every detail of
the process.
 The Context maintains a reference to a strategy object and calls its
methods to perform the task, allowing for interchangeable strategies to be
used.
2. Strategy Interface
An abstract class or interface known as the Strategy Interface specifies a set
of methods that all concrete strategies must implement.
 As a kind of agreement, it guarantees that all strategies follow the same
set of rules and are interchangeable by the Context.
 The Strategy Interface promotes flexibility and modularity in the design by
establishing a common interface that enables decoupling between the
Context and the specific strategies.
3. Concrete Strategies
Concrete Strategies are the various implementations of the Strategy
Interface. Each concrete strategy provides a specific algorithm or behavior
for performing the task defined by the Strategy Interface.
 Concrete strategies encapsulate the details of their respective algorithms
and provide a method for executing the task.
 They are interchangeable and can be selected and configured by the
client based on the requirements of the task.
4. Client
The Client is responsible for selecting and configuring the appropriate
strategy and providing it to the Context.
 It knows the requirements of the task and decides which strategy to use
based on those requirements.
 The client creates an instance of the desired concrete strategy and
passes it to the Context, enabling the Context to use the selected strategy
to perform the task.
Communication between the Components
In the Strategy Design Pattern, communication between the components
occurs in a structured and decoupled manner. Here’s how the components
interact with each other:
 Client to Context:
o The Client, which knows the requirements of the task, interacts
with the Context to initiate the task execution.
o The Client selects an appropriate strategy based on the task
requirements and provides it to the Context.
o The Client may configure the selected strategy before passing it
to the Context if necessary.
 Context to Strategy:
o The Context holds a reference to the selected strategy and
delegates the task to it.
o The Context invokes a method on the strategy object, triggering
the execution of the specific algorithm or behavior encapsulated
within the strategy.
 Strategy to Context:
o Once the strategy completes its execution, it may return a result
or perform any necessary actions.
o The strategy communicates the result or any relevant information
back to the Context, which may further process or utilize the
result as needed.
 Strategy Interface as Contract:
 o The Strategy Interface serves as a contract that defines a set of
methods that all concrete strategies must implement.
o The Context communicates with strategies through the common
interface, promoting interchangeability and decoupling.
 Decoupled Communication:
o Since the components’ communication is decoupled, the Context
is not required to be aware of the exact details of how each
strategy carries out the task.
o As long as they follow the same interface, strategies can be
switched or replaced without affecting the client or other
strategies.
Real-World Analogy of Strategy Design Pattern
Imagine you’re planning a trip to a new city, and you have several options for
getting there: by car, by train, or by plane. Each mode of transportation
offers its own set of advantages and disadvantages, depending on factors
such as cost, travel time, and convenience.

Proxy Design Pattern

The Proxy Design Pattern a structural design pattern is a way to use a
placeholder object to control access to another object. Instead of interacting
directly with the main object, the client talks to the proxy, which then
manages the interaction. This is useful for things like controlling access,
delaying object creation until it’s needed (lazy initialization), logging, or
adding security checks.
A real-world example can be a cheque or credit card as a proxy for what is in
our bank account. It can be used in place of cash and provides a means of
accessing that cash when required.
What is Proxy Design Pattern?
The Proxy Design Pattern is a design pattern in which the client and the
actual object are connected by a proxy object. The client communicates with
the proxy, which manages access to the real object, rather than the real
object directly. Before sending the request to the real object, the proxy can
take care of additional tasks like caching, security, logging, and lazy loading.
Chaining of Proxies
Chaining proxies in the Proxy Design Pattern means connecting them in a
sequence, where each proxy adds its behavior or checks before passing the
request to the next proxy or the real object. It’s like forming a chain of
guards, each responsible for a specific task.

Components of Proxy Design Pattern

1. Subject
The Subject is an interface or an abstract class that defines the common
interface shared by the RealSubject and Proxy classes. It declares the
methods that the Proxy uses to control access to the RealSubject.
 Declares the common interface for both RealSubject and Proxy.
 Usually includes the methods that the client code can invoke on
the RealSubject and the Proxy.
2. RealSubject
The RealSubject is the actual object that the Proxy represents. It contains the
real implementation of the business logic or the resource that the client code
wants to access.
 It Implements the operations declared by the Subject interface.
 Represents the real resource or object that the Proxy controls access to.
3. Proxy
The Proxy acts as a surrogate or placeholder for the RealSubject. It controls
access to the real object and may provide additional functionality such as
lazy loading, access control, or logging.
 Implements the same interface as the RealSubject (Subject).
 Maintains a reference to the RealSubject.
 Controls access to the RealSubject, adding additional logic if necessary.
How to implement Proxy Design Pattern?
Below are the simple steps to implement the Proxy Design Pattern:
1. Create the Real Object Interface: Define an interface or abstract class
that represents the operations the real object will provide. Both the real
object and proxy will implement this interface.
2. Create the Real Object: This class implements the interface and contains
the actual logic or operation that the client wants to use.
3. Create the Proxy Class: The proxy class also implements the same
interface as the real object. It holds a reference to the real object and
controls access to it. The proxy can add extra logic like logging, caching,
or security checks before calling the real object’s methods.
4. Client Uses the Proxy: Instead of creating the real object directly, the
client interacts with the proxy. The proxy decides when and how to
forward the client’s request to the real object.
Proxy Design Pattern example (with implementation)
Problem Statement:
Consider a scenario where your application needs to load and display
images, and you want to optimize the image loading process. Loading
images from disk or other external sources can be resource-intensive,
especially if the images are large or stored remotely.
Facade Method Design Pattern
Facade Method Design Pattern is a part of the Gang of Four design patterns
and it is categorized under Structural design patterns. Before we go into the
details, visualize a structure. The house is the facade, it is visible to the
outside world, but beneath it is a working system of pipes, cables, and other
components that allow the building to run. It provides an easy-to-use
interface so that users may interact with the system.

What is the Facade Method Design Pattern?

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

In the above diagram,

 Structuring a system into subsystems helps reduce complexity.
 A common design goal is to minimize the communication and
dependencies between subsystems.
 One way to achieve this goal is to introduce a Facade object that provides
a single simplified interface to the more general facilities of a subsystem.
When to use Facade Method Design Pattern
 A Facade provide a simple default view of the subsystem that is good
enough for most clients.
 There are many dependencies between clients and the implementation
classes of an abstraction.
 A Facade to decouple the subsystem from clients and other subsystems,
thereby promoting subsystem independence and portability.
 Facade define an entry point to each subsystem level. If subsystem are
dependent, then you can simplify the dependencies between them by
making them communicate with each other through their facades.
Key Components of Facade Method Design Pattern
In the above diagram, Consider for example a programming environment
that gives applications access to its compiler subsystem.
 This subsystem contains classes such as Scanner,Parser, ProgramNode,
BytecodeStream, and ProgramNodeBuilder that implement the compiler.
 Compiler class acts as a facade: It offers clients a single, simple interface
to the compilersubsystem.
 It glues together the classes that implement compilerfunctionality without
hiding themcompletely.
 The compiler facade makes life easier for most programmers without
hiding the lower-level functionality from the few that need it.
1. Facade (Compiler)
 Facade knows which subsystem classes are responsible for a request.
 It delegate client requests to appropriate subsystem objects.
2. Subsystem classes (Scanner, Parser, ProgramNode, etc.)
 It implement subsystem functionality.
 It handle work assigned by the Facade object.
 It have no knowledge of the facade; that is, they keep no references to it.
3. Interface
 The Interface in the Facade Design Pattern refers to the set of simplified
methods that the facade exposes to the client.
 It hides the complexities of the subsystem, ensuring that clients interact
only with high-level operations, without dealing with the underlying details
of the system.
Facade Method Design Pattern collaborate in different way
 Client communicate with the subsystem by sending requests to Facade,
which forwards them to the appropriate subsystem objects.
 The Facade may have to do work of its own to translate it inheritance to
subsystem interface.
 Clients that use the Facade don’t have to access its subsystem objects
directly.
Steps to implement Facade Design Pattern
Below are the simple steps to implement the Facade Design Pattern:
 Step 1: First, determine the complex subsystems or components that the
client needs to interact with.
 Step 2: Build a facade class that serves as the middle layer between the
client and the subsystems. This class should offer simplified methods that
wrap the interactions with the subsystems.
 Step 3: Expose a clear, high-level interface in the facade class. This
interface will include the methods that the client will use, hiding the
internal complexity.
 Step 4: Inside the facade methods, delegate the requests to the
appropriate subsystem classes to perform the actual operations.
 Step 5: The client now interacts only with the facade, which manages the
underlying calls to the subsystems, simplifying the client’s experience.
Exmaple for the Facade Method Design Pattern (with
implementation)

Problem Statement:
Let’s consider a hotel. This hotel has a hotel keeper. There are a lot of
restaurants inside the hotel e.g. Veg restaurants, Non-Veg restaurants, and
Veg/Non Both restaurants. You, as a client want access to different menus of
different restaurants.
 You do not know what are the different menus they have. You just have
access to a hotel keeper who knows his hotel well.
 Whichever menu you want, you tell the hotel keeper and he takes it out of
the respective restaurants and hands it over to you.

The Gang of Four (GOF) patterns are set of 23 common software design
patterns introduced in the book Design Patterns: Elements of Reusable
Object-Oriented Software.

GRASP Design Principles in OOAD

In Object-Oriented Analysis and Design (OOAD), General Responsibility
Assignment Software Patterns (GRASP) play a crucial role in designing
effective and maintainable software systems. GRASP offers a set of
guidelines to aid developers in assigning responsibilities to classes and
objects in a way that promotes low coupling, high cohesion, and overall
robustness. By understanding and applying GRASP principles, developers
can create software solutions that are flexible, scalable, and easier to
maintain over time.