• Singleton Pattern

• The Singleton method or Singleton Design pattern is one of the simplest design
patterns. It ensures a class only has one instance, and provides a global point of
access to it.
• Factory Method Pattern
• The Factory Method pattern is used to create objects without specifying the
exact class of object that will be created. This pattern is useful when you need to
decouple the creation of an object from its implementation.
• Abstract Factory Pattern
• Abstract Factory pattern is almost similar to Factory Pattern and is considered as
another layer of abstraction over factory pattern. Abstract Factory patterns work around
a super-factory which creates other factories.
• Builder Pattern
• Builder pattern aims to “Separate the construction of a complex object from its
representation so that the same construction process can create different
representations.” It is used to construct a complex object step by step and the final step
will return the object.
• Prototype Pattern Prototype allows us to hide the complexity of making new instances
from the client.
• The concept is to copy an existing object rather than creating a new instance from
scratch, something that may include costly operations. The existing object acts as a
prototype and contains the state of the object.

• Adapter Pattern
• The adapter pattern convert the interface of a class into another interface clients expect. Adapter lets classes work together
that couldn’t otherwise because of incompatible interfaces
• Bridge Pattern
• The bridge pattern allows the Abstraction and the Implementation to be developed independently and the client code can
access only the Abstraction part without being concerned about the Implementation part.
• Composite Pattern
• Composite pattern is a partitioning design pattern and describes a group of objects that is treated the same way as a single
instance of the same type of object. The intent of a composite is to “compose” objects into tree structures to represent part-
whole hierarchies.
• Decorator Pattern
• It allows us to dynamically add functionality and behavior to an object without affecting the behavior of other existing
objects within the same class.
• 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 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.
• Proxy Pattern
• 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.
• Proxies are also called surrogates, handles, and wrappers. They are closely related in structure, but not purpose, to Adapters
and Decorators.
• Flyweight Pattern
• This pattern provides ways to decrease object count thus improving application required objects structure. Flyweight pattern
is used when we need to create a large number of similar objects.

• Observer Pattern
• It defines a one-to-many dependency between objects, so that when one object (the subject) changes its state, all its
dependents (observers) are notified and updated automatically.
• Strategy Pattern
• that allows the behavior of an object to be selected at runtime. It is one of the Gang of Four (GoF) design patterns, which are
widely used in object-oriented programming.
• The Strategy pattern is based on the idea of encapsulating a family of algorithms into separate classes that implement a
common interface.
• Command Pattern
• The Command Pattern is a behavioral design pattern that turns a request into a stand-alone object, containing all the
information about the request. This object can be passed around, stored, and executed at a later time
• Chain of Responsibility Pattern
• 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.
• 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.
• State Pattern
• A state design pattern is used when an Object changes its behavior based on its internal state. 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.
• Template Method Pattern
• Template method design pattern is to define an algorithm as a skeleton of operations and leave the details to be implemented
by the child classes. The overall structure and sequence of the algorithm are preserved by the parent class.
• Visitor Pattern
• 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.
• Interpreter Pattern
• Interpreter pattern is used to defines a grammatical representation for a language and provides an interpreter to deal with this
grammar.
• Mediator Pattern
• It enables decoupling of objects by introducing a layer in between so that the interaction between objects happen via the layer.
• Memento Pattern
• It is used to restore state of an object to a previous state. As your application is progressing, you may want to save checkpoints
Nemin Sheth in your application and restore back to those checkpoints later.
• Intent of Memento Design pattern is without violating encapsulation, capture and externalize an object’s internal state so that
the object can be restored to this state later.
 Selecting a Design Pattern

• Consider how design patterns solve

design problems
• Scan Intent sections
• Study how patterns interrelate
• Study patterns of like purpose.
• Examine a cause of redesign
• Consider what should be variable in
your design

How Design Patterns Solve Design Problems

• Finding Appropriate Objects

• Requests are the only way to get an object to execute an operation. Operations are the only way to change an object’s internal data. Because
of these restrictions, the object’s internal state is said to be encapsulated; it cannot be accessed directly, and its representation is invisible from
outside the object.
• The hard part about object-oriented design is decomposing a system into objects. The task is difficult because many factors come into play:
encapsulation, granularity, dependency, flexibility, performance, evolution, reusability, and on and on. They all influence the decomposition,
often in conflicting ways
• For example, the Composite pattern introduces an abstraction for treating objects uniformly that doesn’t have a physical counterpart.
• The Strategy pattern describes how to implement interchangeable families of algorithms.
• The State pattern represents each state of an entity as an object

• Determining Object Granularity

• Objects can vary tremendously in size and number. They can represent everything down to the hardware or all the way up to entire
applications. How do we decide what should be an object?
• Design patterns address this issue as well.
• The Facade pattern describes how to represent complete subsystems as objects, and the Flyweight pattern describes how to support huge
numbers of objects at the finest granularities.
• Other design patterns describe specific ways of decomposing an object into smaller objects.

• Specifying Object Interfaces

• An object’s interface characterizes the complete set of requests that can be sent to the object. Any request that matches a signature in the
object’s interface may be sent to the object.

• Specifying Object Implementations

• For example, objects in a Chain of Responsibility must have a common type, but usually they don’t share a common implementation.
• In the Composite pattern, Component defines a common interface, but Composite often defines a common implementation.
• Command , Observer , State , and Strategy are often implemented with abstract classes that are pure interfaces.

How to Use a Design Pattern

• Read the pattern once through for an overview.
• Go back and study the Structure, Participants, and Collaborations sections
• Look at the Sample Code section to see a concrete example of the pattern in code.
• Choose names for pattern participants that are meaningful in the application context
• Define the classes
• Define application-specific names for operations in the pattern
• Implement the operations to carry out the responsibilities and collaborations in the pattern

Nemin Sheth
Creational Design Patterns
Creational Design Pattern responsibility is to create objects / controls the creation of objects.

Prototype
It is used when we have to make copy/clone from existing Object.

Singleton Pattern
It is used when we to create only 1 instance of a class.
(Eager, Lazy, Synchronised,Double Locking)

Factory Pattern
It is used when all the Object creation and business logic we need to keep at one place.

Abstract Factory Patter

It is a factory of factory.

Builder Pattern
It is used when you want to create Object step by step.

Structural Design Pattern

Is a way to combine or arrange different classes and objects to form a complex or bigger structure to solve a particular
requirement.

Decorator Pattern
This pattern helps to add more functionality to existing Object, without changing its structure.

Proxy Patter
This pattern helps to provide control access to original Object.

Composite Pattern
This pattern helps in scenarios where we have Object inside Object (tree like structure)

Adapter Pattern
This pattern acts as a bridge or an intermediate between two incompatible interfaces. (Client- Adapter- Adaptee)

Bridge Pattern
This pattern helps to decouple an abstraction from its implementation, so that two can vary independently.

Facade Patter
This pattern helps to hide the complexity of system from the client. (Client- Facade- DAO)

Flyweight Pattern
This pattern helps to reduce memory usage by sharing data among multiple Objects. (Intrinsic data and Extrinsic data)

Nemin Sheth