design patterns

1. Here's a summary of some common design paterns:
Crea�onal Paterns:
1. Singleton Patern:
• Intent: Ensure a class has only one instance and provide a global
point of access to it.
• Use Case: When exactly one object is needed to coordinate ac�ons
across the system.
2. Factory Method Patern:
• Intent: Define an interface for crea�ng an object, but let subclasses
alter the type of objects that will be created.
• Use Case: When a class cannot an�cipate the class of objects it must
create.
3. Abstract Factory Patern:
• Intent: Provide an interface for crea�ng families of related or
dependent objects without specifying their concrete classes.
• Use Case: When a system must be configured with mul�ple families
of objects.
4. Builder Patern:
• Intent: Separate the construc�on of a complex object from its
representa�on, allowing the same construc�on process to create
various representa�ons.
• Use Case: When an object needs to be constructed with numerous
possible configura�ons.
5. Prototype Patern:
• Intent: Specify the kinds of objects to create using a prototypical
instance, and create new objects by copying this prototype.
• Use Case: When the cost of crea�ng an object is more expensive than
copying an exis�ng one.

2. 6. Object Pool Patern:
• Intent: Reuse and manage a pool of objects, rather than crea�ng and
destroying them on demand.
• Use Case: When the cost of ini�alizing an object is high, and the rate
of instan�a�on of a class is high.
7. Lazy Ini�aliza�on Patern:
• Intent: Delay the crea�on of an object or the computa�on of a value
un�l it is actually needed.
• Use Case: When the instan�a�on of an object is resource-intensive
and might not be necessary during the life�me of the program.
Each of these crea�onal paterns addresses different aspects of object crea�on,
such as controlling the number of instances, providing a flexible mechanism for
crea�ng objects, or op�mizing the crea�on process based on specific
requirements. Choosing the right crea�onal patern depends on the problem at
hand and the desired characteris�cs of the solu�on.
Structural Paterns:
1. Adapter Patern:
• Intent: Allows the interface of an exis�ng class to be used as another
interface.
• Use Case: When the interface of an exis�ng class does not match
what a client expects.
2. Bridge Patern:
• Intent: Separates an abstrac�on from its implementa�on so that the
two can vary independently.
• Use Case: When changes in the implementa�on of an abstrac�on
should not affect clients.
3. Composite Patern:

3. • Intent: Composes objects into tree structures to represent part-
whole hierarchies.
• Use Case: When clients need to treat individual objects and
composi�ons of objects uniformly.
4. Decorator Patern:
• Intent: Ataches addi�onal responsibili�es to an object dynamically.
• Use Case: When the behavior of objects needs to be extended
without altering their code.
5. Facade Patern:
• Intent: Provides a simplified interface to a set of interfaces in a
subsystem.
• Use Case: When there is a complex subsystem, and a simpler
interface is needed for a specific set of func�onality.
6. Flyweight Patern:
• Intent: Uses sharing to support a large number of fine-grained
objects efficiently.
• Use Case: When a large number of similar objects need to be created
and memory usage is a concern.
7. Proxy Patern:
• Intent: Provides a surrogate or placeholder for another object to
control access to it.
• Use Case: When you want to control access to an object, add
func�onality before or a�er the request is passed.
8. Composite Patern:
• Intent: Composes objects into tree structures to represent part-
whole hierarchies.
• Use Case: When clients need to treat individual objects and
composi�ons of objects uniformly.

4. These structural paterns help in organizing code in a way that promotes flexibility,
reusability, and simplicity. They address concerns related to the composi�on of
classes and objects, making it easier to manage complex systems and adapt them
to changing requirements.
Behavioral Paterns:
1. Observer Patern:
• Intent: Defines a one-to-many dependency between objects so that
when one object changes state, all its dependents are no�fied and
updated automa�cally.
• Use Case: When a change in one object should trigger changes in
other objects without making them �ghtly coupled.
2. Strategy Patern:
• Intent: Defines a family of algorithms, encapsulates each one, and
makes them interchangeable.
• Use Case: When you want to define a family of algorithms,
encapsulate each one, and make them interchangeable. Clients can
choose the algorithm at run�me.
3. Command Patern:
• Intent: Encapsulates a request as an object, thereby allowing for
parameteriza�on of clients with different requests, queuing of
requests, and logging of the parameters.
• Use Case: When you want to parameterize objects with opera�ons,
queue requests, and support undoable opera�ons.
4. Chain of Responsibility Patern:
• Intent: Passes a request 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.

5. • Use Case: When you want to decouple the sender and receiver of a
request and allow more than one object to handle a request.
5. State Patern:
• Intent: Allows an object to alter its behavior when its internal state
changes. The object will appear to change its class.
• Use Case: When an object's behavior depends on its state and needs
to change its behavior at run�me.
6. Visitor Patern:
• Intent: Represents an opera�on to be performed on the elements of
an object structure. It lets you define a new opera�on without
changing the classes of the elements on which it operates.
• Use Case: When you have a complex object structure and want to
perform various opera�ons on its elements.
7. Interpreter Patern:
• Intent: Defines a grammar for interpre�ng the sentences in a
language and provides an interpreter to interpret those sentences.
• Use Case: When you need to interpret sentences in a language and
represent them as a set of opera�ons.
8. Memento Patern:
• Intent: Captures and externalizes an object's internal state so that the
object can be restored to this state later.
• Use Case: When you need to capture and restore an object's internal
state, such as for undo mechanisms.
These behavioral paterns address the ways in which objects collaborate and
communicate, allowing for more flexible and maintainable systems. The choice of
patern depends on the specific requirements and scenarios in a given applica�on.

6. Architectural Paterns:
1. Model-View-Controller (MVC):
• Intent: Separates an applica�on into three interconnected
components - Model (data and business logic), View (user interface),
and Controller (handles user input and updates the model and view).
• Use Case: When you want to separate concerns related to data, user
interface, and user input in an applica�on.
2. Model-View-ViewModel (MVVM):
• Intent: Enhances the separa�on of concerns by introducing a
ViewModel, which abstracts the state and behavior of the View.
• Use Case: Par�cularly useful in GUI-based applica�ons where the
ViewModel handles the user interface logic independently of the
View.
3. Repository Patern:
• Intent: Mediates between the data source and the business logic or
domain, providing a clean API for data access.
• Use Case: When you want to abstract the underlying data access
details and provide a consistent interface for accessing data.
4. Dependency Injec�on (DI):
• Intent: Allows the crea�on and injec�on of dependent objects,
decoupling the classes and making the system more modular and
testable.
• Use Case: When you want to achieve a high level of reusability,
testability, and maintainability by promo�ng loose coupling between
components.
5. Microservices Architecture:

7. • Intent: Decomposes an applica�on into a set of small, independent
services that communicate with each other through well-defined
APIs.
• Use Case: Suitable for large, complex applica�ons where scalability,
maintainability, and con�nuous deployment are cri�cal.
6. Event-Driven Architecture (EDA):
• Intent: Emphasizes the produc�on, detec�on, consump�on, and
reac�on to events in a system, allowing for loose coupling between
components.
• Use Case: When you want to build scalable and responsive systems
that react to events or changes in the environment.
7. Serverless Architecture:
• Intent: Enables building and running applica�ons without managing
the underlying server infrastructure. Func�ons are executed in
response to events or triggers.
• Use Case: For applica�ons with variable workloads, where you only
pay for the actual compute resources used.
8. Hexagonal Architecture (Ports and Adapters):
• Intent: Separates the core business logic (hexagon) from external
concerns (ports and adapters), making the system more adaptable to
changes in external interfaces.
• Use Case: Useful when dealing with mul�ple external systems or
interfaces.
These architectural paterns provide guidelines for organizing and structuring
so�ware systems, helping developers create robust, scalable, and maintainable
applica�ons. The choice of patern depends on the specific requirements and
goals of the applica�on being developed.

8. Concurrency Paterns:
1. Producer-Consumer Patern:
• Intent: Involves two types of processes - producers that generate
data, and consumers that process the data. A shared buffer facilitates
communica�on between producers and consumers.
• Use Case: When you have one or more processes producing data and
one or more processes consuming and processing that data.
2. Reader-Writer Patern:
• Intent: Manages access to a shared resource, allowing mul�ple
readers simultaneous access but ensuring exclusive access for a
writer.
• Use Case: When you have a shared resource that is read by mul�ple
threads but modified by a single thread.
3. Semaphore Patern:
• Intent: Controls access to a common resource by a limited number of
threads. Semaphores maintain a count of available resources.
• Use Case: When you want to control the number of threads accessing
a resource simultaneously.
4. Mutex Patern:
• Intent: Ensures that only one thread can access a resource at a �me.
It provides mutual exclusion to prevent race condi�ons.
• Use Case: When you need to protect shared resources from
concurrent access.
5. Barrier Patern:
• Intent: Synchronizes a group of threads by making them wait at a
predefined point un�l all threads have reached that point.

9. • Use Case: When you want to ensure that all threads have completed
a specific phase of execu�on before proceeding.
6. Thread Pool Patern:
• Intent: Manages a pool of worker threads, reusing them to execute a
large number of lightweight tasks.
• Use Case: When you have a large number of tasks to perform, and
crea�ng a new thread for each task is inefficient.
7. Immutable Object Patern:
• Intent: Ensures that an object's state cannot be modified a�er it is
created, elimina�ng the need for locks in concurrent access.
• Use Case: When you want to simplify concurrency control by making
objects thread-safe through immutability.
8. Double-Checked Locking Patern:
• Intent: Reduces the overhead of acquiring locks by checking a lock
condi�on without entering the cri�cal sec�on, poten�ally avoiding
unnecessary locking.
• Use Case: When you want to op�mize performance by minimizing
the use of locks in scenarios where conten�on is low.
9. Reactor Patern:
• Intent: Handles concurrent I/O opera�ons by dispatching events to
appropriate handlers. It's o�en used in networking applica�ons.
• Use Case: When you have a large number of concurrent I/O
opera�ons and want to handle them efficiently.
These concurrency paterns provide solu�ons to common challenges in
mul�threaded and parallel programming. Applying these paterns correctly can
help improve the performance, reliability, and maintainability of concurrent
systems.

10. Cloud Paterns:
Cloud design paterns are architectural solu�ons that address common challenges
encountered when designing and deploying applica�ons in cloud environments.
These paterns help developers and architects take advantage of cloud services
and best prac�ces to build scalable, resilient, and efficient systems. Here's an
overview of some key cloud design paterns:
1. Microservices Architecture:
• Intent: Decompose a large, monolithic applica�on into smaller,
independent services that can be developed, deployed, and scaled
independently.
• Use Case: Well-suited for building and maintaining large and complex
applica�ons with different func�onal components.
2. Serverless Architecture:
• Intent: Focuses on building applica�ons without managing server
infrastructure. Func�ons are executed in response to events or
triggers.
• Use Case: Ideal for event-driven and sporadically used workloads
where scalability and cost-effec�veness are crucial.
3. Strangler Patern:
• Intent: Gradually migrate from a monolithic system to a
microservices architecture by incrementally replacing components.
• Use Case: Useful when you want to modernize legacy applica�ons
without a complete rewrite.
4. Circuit Breaker Patern:
• Intent: Prevents a network or service failure from cascading to other
parts of the applica�on. It detects faults and "opens the circuit" to
prevent further damage.
• Use Case: Ensures the resilience of the system against failures in
dependent services.

11. 5. Retry Patern:
• Intent: Automa�cally retries a failed opera�on with the expecta�on
that it might succeed on subsequent atempts.
• Use Case: Mi�gates transient failures in network communica�ons or
external services.
6. Bulkhead Patern:
• Intent: Isolates components or services to prevent a failure in one
part of the system from affec�ng the availability of other parts.
• Use Case: Helps in containing failures and ensuring the overall
system's availability.
7. Event Sourcing Patern:
• Intent: Stores the state of an applica�on as a sequence of events.
Enables reconstruc�on of the applica�on state at any point in �me.
• Use Case: Useful when you need a full audit trail of changes and the
ability to replay events for different views of data.
8. Saga Patern:
• Intent: Manages distributed transac�ons and long-running business
processes by breaking them into a series of smaller, isolated steps.
• Use Case: Ensures consistency in a distributed environment where
transac�ons span mul�ple services.
9. Ambassador Patern:
• Intent: Offloads common client-side func�ons (e.g., load balancing,
authen�ca�on) to a separate, reusable component.
• Use Case: Improves maintainability by centralizing cross-cu�ng
concerns in a single component.
10.Gateway Aggrega�on Patern:
• Intent: Aggregates mul�ple requests into a single request to reduce
the number of round-trips between the client and the server.

12. • Use Case: Enhances performance by minimizing the overhead of
mul�ple requests.
These paterns provide guidance on how to design, implement, and deploy
applica�ons in cloud environments effec�vely. They help address challenges
related to scalability, availability, reliability, and efficiency in the context of cloud
compu�ng. The choice of paterns depends on the specific requirements and
constraints of the applica�on being developed.
These paterns are not one-size-fits-all solu�ons but rather guidelines for solving
common problems.