In this file 2 units of Design Patterns are covered

1. UNIT – 1
Introductionto DesignPattern
- Designing object-oriented softwareis hard, and designing reusable object-oriented
softwareis even harder.
- It takes a long timefor novices to learn what good object-oriented design is all
about. Experienced designers evidently know something inexperienced ones don't.
- Expert designers find recurring patterns of classes and communicatingobjects in
many object-oriented systems, and can apply them immediately to design problems
without having to rediscover them.
- Recording experience in designing object-oriented softwareas design patterns.
- Design patterns makeit easier to reuse successful designs and architectures.
-
What is a DesignPattern?
- • Christopher Alexander says, "Each pattern describes a problem which occurs over
and over again in our environment, and then describes thecoreof thesolution to
that problem, in such a way that you can usethis solution a million times over,
without ever doing it thesameway twice".
- • Four essential elements of a pattern::
- 1. The pattern name is a handlewe can useto describea design problem, its
solutions, and consequences in a word or two.
- 2. The problem describes when to apply thepattern.
- 3. The solution describes theelements that makeup thedesign, their relationships,
responsibilities, and collaborations
- 4. The consequences aretheresults and trade-offs of applying thepattern.
- • The design patterns are descriptions of communicating objects andclasses that are
customized to solve a general designproblemin a particular context.
Describing of DesignPatterns
• Pattern Name and Classification
• Intent
- What does thedesign pattern do? What is its rationaleand intent? What particular
design issueor problem does it address?
• Also Known As
• Motivation
- A scenario that illustrates a design problem and how theclass and object structures
in the pattern solvetheproblem.
• Applicability
- What are thesituations in which thedesign pattern can beapplied?

2. • Structure
- A graphical representation of theclasses in thepattern using a notation based on
OMT or UML.
• Participants
- The classes and/or objects participating in thedesign pattern and their
responsibilities.
• Collaborations
- How theparticipants collaborateto carry out their responsibilities.
• Consequences
- How does thepattern support its objectives? What arethe trade-offs and results of
using thepattern?
• Implementation
- What should you beaware of when implementing thepattern? Aretherelanguage-
specific issues?
• Sample Code
- Code fragments that illustratehow you mightimplementthepattern in particular
object-oriented programming languages.
• Known Uses
- Examples of the pattern found in real systems.
• Related Patterns
The Catalog of DesignPatterns
1.0 Abstract Factory provides an interfacefor creating families of related or dependent
objects without specifying their concreteclasses.
2.0 Adapter converts theinterfaceof a class into another interfaceclients expect.
Adapter lets classes work together that couldn't otherwisebecauseof incompatible
interfaces.
3.0 Bridge decouples an abstraction fromits implementation so that thetwo can vary
independently.
4.0 Builder separates theconstruction of a complex object from its representation so
that thesameconstruction process can createdifferent representations.
5.0 Chain of Responsibility avoids couplingthesender of a request to its receiver by
giving morethan oneobject a chance to handletherequest. Chain the receiving objects
and pass therequest along thechain until an object handles it.

3. 6.0 Command encapsulates a request as an object, thereby letting you parameterize
clients with different requests, queueor log requests, and support undoable
operations.
7.0 Composite composes objects into treestructures to represent part-whole
hierarchies. Compositelets clients treat individual objects and compositionsof objects
uniformly.
8.0 Decorator attaches additional responsibilities to an object dynamically. Decorators
providea flexible alternativeto subclassing for extending functionality.
9.0 Facade provides a unified interfaceto a set of interfaces in a subsystem. Facade
defines a higher-level interface that makes thesubsystem easier to use.
10.0 Factory Method defines an interfacefor creating an object, but let subclasses
decide which class to instantiate. Factory Method lets a class defer instantiation to
subclasses.
11.0 Flyweight uses sharing to support largenumbersof fine-grained objects efficiently.
12.0 Interpreter, givena language, defines arepresentionfor its grammar alongwith an
interpreter that uses therepresentation to interpret sentences in thelanguage.
13.0 Iterator provides a way to access theelements of an aggregate object sequentially
without exposing its underlying representation.
14.0 Mediator defines an object that encapsulates how a set of objects interact.
15.0 Memento, withoutviolating encapsulation, captures and externalizes an object's
internal stateso that theobject can be restored to this statelater.
16.0 Observer defines a one-to-many dependency between objects so that when one
Object changes state, all its dependents arenotified and updated automatically.
17.0 Prototype specifies thekinds of objects to createusing a prototypicalinstance,
and create new objects by copying this prototype.
18.0 Proxy provides a surrogateor placeholder for another object to control access to
it.
19.0 Singleton ensures a class only has oneinstance, and providea global point of
access to it.
20.0 State allows an object to alter its behavior when its internal statechanges. The
object will appear to changeits class.
21.0 Strategy defines a family of algorithms, encapsulateeach one, and makethem
interchangeable. Strategy lets thealgorithm vary independently from clientsthat useit.
22.0 Template Method defines theskeleton of an algorithmin an operation, deferring
somesteps to subclasses. TemplateMethodlets subclasses redefinecertain steps of an
algorithm without changingthealgorithm's structure.
23.0 Visitor represents an operation to beperformed on theelements of an object
structure. Visitor lets you definea new operation without changing theclasses of the
elements on which it operates.

4. Catalog and organizationof catalog
- We classify design patterns by two criteria. Thefirst criterion, called purpose,
reflects what a pattern does. Patterns can havecreational, structural, or behavioral
purpose. Creational patterns concern theprocess of object creation. Structural
patterns deal with thecomposition of classes or objects. Behavioral patterns
characterizetheways in which classes or objects interact and distribute
responsibility.
- The second criterion, called scope, specifies whether the pattern applies primarily to
classes or to objects. Class patterns deal with relationshipsbetween classes and their
subclasses. These relationships areestablished through inheritance, so they are
static—fixed at compile-time. Object patterns deal with object relationships, which
can bechanged at run-timeand aremoredynamic.
-
-
Design Patterns to solve design problems
- Design patterns solvemany of theday-to-day problems object-oriented designers
face, and in many different ways. Hereare several of theseproblems and how
design patterns solvethem.
1. Finding Appropriate Objects
- Object-oriented programs are made up of objects.
- An object packages both data and the procedures that operateon that data.
The procedures aretypically called methods or operations.

5. - An object performs an operation when it receives a request (or message) from a
client.
- Object-oriented design methodologies favor manydifferent approaches.
- You can writea problem statement, single out thenouns and verbs, and create
corresponding classes and operations.
- Or you can focus on the collaborations and responsibilities in your system.
- Or you can model thereal world and translatethe objects found during analysis into
design.
- There will always be disagreement on which approach is best.
2. Determining Object Granularity
- Objects can vary tremendously in sizeand number.
- The Facadepattern describes how to represent completesubsystems as objects, and
theFlyweight pattern describes how to support hugenumbersof objects at theinest
granularities.
- Other design patterns describespecific ways of decomposing an object into smaller
objects.
- Abstract Factory and Builder yield objects whoseonly responsibilities arecreating
other objects.
- Visitor and Command yield objects whoseonly responsibilities areto implement a
request on another object or group of objects.
3. Specifying Object Interfaces
- Every operation declared by an object specifies theoperation's name, theobjects it
takes as parameters, and theoperation's return value. This is known as the
operation's signature.
- The set of all signatures defined by an object's operations is called theinterfaceto
theobject.
- An object's interfacecharacterizes thecompleteset of requests that can be sent to
theobject.
- Any request that matches a signaturein theobject's interfacemay besent to the
object.
- Interfaces are fundamental in object oriented systems.
- Objects are known only through their interfaces.
- There is no way to know anything about an object or to ask it to do anything without
going through its interface.
- An object's interfacesays nothing about its implementation—differentobjects are
free to implement requests differently.
- That means two objects having completely different implementationscan have
identical interfaces.
4. Specifying Object Implementations
- An object's implementation is defined by its class.
- The class specifies theobject's internal data and representation and defines the
operations theobject can perform.

6. - Our OMT-based notation depicts a class as a rectanglewith theclass namein bold.
- Operations appear in normal typebelow theclass name.
- Any data that theclass defines comes after the operations;
- Lines separatethe class namefrom theoperations and theoperations from thedata:
- Return types and instancevariabletypes areoptional, sincewedon't assumea
statically typed implementation language.
- Objects are created by instantiatinga class.
- The object is said to be an instanceof theclass.
- The process of instantiating a class allocates storagefor theobject's internal data
and associates theoperations with thesedata.
- Many similar instances of an object can becreated by instantiating a class.
- A dashed arrowhead line indicates a class that instantiatesobjects of another class.
- The arrow points to theclass of theinstantiated objects.
- New classes can be defined in terms of existing classes using class inheritance.
- When a subclass inherits from a parent class, it includes thedefinitions of all the
data and operations that the parent class defines.
- Objects that are instances of thesubclass will contain all data defined by the
subclass and its parent classes, and they'll beableto perform all operations defined
by this subclass and its parents.
- We indicate thesubclass relationship with a vertical lineand a triangle:
- An abstract class is onewhosemain purposeis to definea common interfacefor its
subclasses.
- An abstract class will defer someor all of its implementation to operations defined in
subclasses; hencean abstract class cannot beinstantiated.
- The operations that an abstract class declares but doesn'timplementare called
abstract operations.
- Classes that aren't abstract arecalled concreteclasses.
- Subclasses can refineand redefine behaviors of their parent classes.
- Morespecifically, a class may overridean operation defined by its parent class.
How to Select a Design Pattern
- With morethan 20 design patterns in thecatalog to choosefrom, it might behard to
find the onethat addresses a particular design problem, especially if thecatalog is
new and unfamiliar to you.
- Here areseveral different approaches to finding thedesign pattern that's right for
your problem:
1. Consider how design patterns solve design problems. Design patternshelp you
find appropriate objects, determineobject granularity, specify object interfaces, and several
other ways in which design patterns solvedesign problems. Referring to thesediscussions
can help guideyour search for theright pattern.
2. Scan Intent sections. Lists theIntent sectionsfrom all thepatterns in thecatalog.
Read through each pattern's intent to find oneor morethat sound relevant to your
problem.

7. 3. Study how patterns interrelate. Relationships between design patterns
graphically. Studying theserelationshipscan help direct you to theright pattern or group of
patterns.
4. Study patterns of like purpose. Thecatalog has threechapters, one for creational
patterns, another for structural patterns, and a third for behavioral patterns. Each chapter
starts off with introductory comments on thepatternsand concludes with a section that
compares and contrasts them. These sections giveyou insightinto thesimilarities and
differences between patterns of likepurpose.
5. Examine a cause of redesign. Look at thecauses of redesign, Then look at the
patterns that help you avoid thecauses of redesign.
6. Consider what should be variable in your design. This approach is theoppositeof
focusing on thecauses of redesign. Instead of considering what might force a changeto a
design, consider what you want to be able to change without redesign.
Use a DesignPattern
- Once you've picked a design pattern, how do you use it? Here's a step-by-step
approach to applying a designpattern effectively:
1. Read the patternonce throughfor anoverview. Pay particular attentionto the
Applicability and Consequences sections to ensure the patternis right for your
problem.
2. Go back and studythe Structure, Participants, and Collaborations sections. Make
sure you understand the classes and objects inthe patternand how they relate to one
another.
3. Look at the Sample Code sectiontosee a concrete example of the patternincode.
Studying the code helps you learn how to implement the pattern.
4. Choose names for patternparticipants that aremeaningful inthe application
context. The names for participants in design patterns are usually too abstract to
appear directlyinan application. Nevertheless, it's useful to incorporate the
participant name into the name that appears in the application. That helps make the
patternmore explicit inthe implementation. For example, if you use the Strategy
patternfor a text compositingalgorithm, thenyou might have classes
SimpleLayoutStrategyor TeXLayoutStrategy.
5. Define the classes. Declaretheir interfaces, establishtheir inheritance
relationships, and define the instance variables that represent data and object
references. Identifyexistingclasses inyour application that the pattern will affect, and
modifythem accordingly.
6. Define application-specific namesfor operations inthe pattern. Here again, the
names generally depend on the application. Use the responsibilities andcollaborations
associatedwith eachoperationas a guide. Also, be consistent inyour naming
conventions. For example, you might use the "Create-" prefix consistentlyto denote a
factorymethod.

8. 7. Implement the operations tocarryout the responsibilitiesand collaborations in
the pattern. The Implementationsectionoffershints to guide you in the
implementation. The examples in the Sample Code sectioncanhelp as well.
Shubham Narkhede 6th
Semester CSE, Design Pstterns

9. UNIT – 2
Creational Patterns
- These patterns support one of the most common tasks in object-oriented
programming is the creation of objects in a system.
- Most Object Oriented systems of any complexity require many objects to be
instantiated over time, and thesepatterns support thecreation processby helping to
provide the following capabilities:
• Generic instantiation – This allows objects to be created in a system without
having to identify a specific class type in code.
• Simplicity – Some of the patterns make object creation easier, so callers will
not have to write large, complex code to instantiate an object.
• Creation constraints – Some patterns enforce constraints on the type or
number of objects that can be created within a system.
- The following patterns are discussed in this chapter:
• Abstract Factory – To provide a contract for creating families of related or
dependent objects without having to specify their concrete classes.
• Builder – To simplify complex object creation by defining a class whose
purposeis to build instances of another class. The Builder produces one main
product,suchthattheremightbemorethanoneclassintheproduct,butthere
is always one main class.
• Factory Method– To definea standardmethodtocreatean object, apartfrom
a constructor, but the decision of what kind of an object to create is left to
subclasses.
• Prototype – To make dynamic creation easier by defining classes whose
objects can create duplicates of themselves.
• Singleton– To haveonlyoneinstanceof thisclassinthesystem,whileallowing
other classes to get access to this instance. Of these patterns, the Abstract
Factory and Factory Method are explicitly based on the concept of defining
flexible object creation; they assume that the classes or interfaces to be
created will be extended in an implementing system. As a result, these two
patterns are frequently combined with other creational patterns.
Abstract Factory Pattern
- Abstract Factory patterns work around a super-factory which creates other
factories.
- This type of design pattern comes under creational pattern as this pattern
provides one of the best ways to create an object.

10. - Abstract Factory pattern, an interface is responsible for creating a factory of
related objects without explicitly specifying their classes.
- Each generated factory can give the objects as per the Factory pattern.
Intent :
- Providean interfacefor creating families of related or dependent objects without
specifying their concreteclasses.
Also known as:
- Kit
- This factory is also called as factory of factories.
Motivation :
- Abstract Factory is used for object creation, just like a Factory method.
- However, the main difference is that it only allows the creation of objects of classes that
are related to each other.
Applicability :
- Use the Abstract Factory pattern when
 A system should be independent of how its products are created, composed, and
represented.
 A system should be configured with one of multiple families of products.
 A family of related product objects is designed to be used together, and you need to
enforce this constraint.
 You want to provide a class library of products, and you want to reveal just their
interfaces, not their implementations.
Structure :

11. Collaboration :
Consequences :
Implementation :
- An example would be of a database library that has classes for using different
databases.
- The library designer may want to keep the library classes loosely coupled with the client
applications, so that new database classes can be easily used with existing applications.
- Let's assume the classes that each database requires are Connection & Command.
- These can be made as abstract classes, with implementations for each database e.g. for
SqlServer, the classes might be SqlCommand & SqlConnection.
- In the same way, for Oracle, the classes factories.
- Each factory will have a factory method that will create instance of a database class.
- This will limit the creation of objects only for a specific database at a time might be
OrConnections & OrCommand.
- The client application will not use the database specific classes directly (to ensure loose
coupling); it will use the abstract classes instead.
- For that, it needs the following:
1. A way to get instances of specific database classes
2. Ensure that the classes can be used only from one database at a time
- This can be accomplished by creating a hierarchy of
Sample Code :
1 //C#
2 class Start
3 {
4 public static void main(String[] args)
5 {
6 useDatabase(new SqlFactory());
7 }
8 static void useDatabase(DbFactory factory)
9 {
10 //Instances will be created only for a specific database
11 Command cmd = factory.CreateCommand();
12 Connection con = factory.CreateConnection();
13 //Use the instances
14 }
15 }
Know Users :
- C# uses Abstract Factory for its ADO.NET database library.
- All the database specific classes can be instantiated through a factory that allows
creation of instances only from one set.
Related Patterns:
- Creational patterns are sometimes competitors as they can be used interchangeably.
- Abstract Factory classes are usually implemented as singletons as only one instance of
factory is useful for creating instances of product classes.
- Abstract Factory uses Factory Method for its implementation.
- Projects initially may start off with Factory Method, and may evolve towards Abstract
Factory, Prototype or Builder, as the designers feel the need for more flexibility.
- Abstract Factory can be used instead of a Façade to hide platform or context
differences.
- To hide platform differences, sometimes a Bridge can also be used.

12. Advantages :
1. Leads to a loosely coupled design.
2. Restricts the usage of classes from one family/configuration at a time.
3. Supporting new configurations is easy.
4. Promotes consistency among classes.
Disadvantages :
1. The number of classes that can be instantiated from each family is fixed in the
interface of the Abstract factory.
 Makes adding new classes difficult.
When to use :
1. When an application should use not be dependent on how the class instances
are created
2. When an application should be configured with one of the multiple families of
classes
3. An application should use classes only from one family at a time
Builder Pattern
Intent :
- Builder pattern builds a complex object using simple objects and using a step by step
approach.
- This type of design pattern comes under creational pattern as this pattern provides one of
the best ways to create an object.
- A Builder class builds the final object step by step. This builder is independent of other
objects.
Also known as:
Motivation :
- The more complex an application is the complexity of classes and objects used
increases.
- Complex objects are made of parts produced by other objects that need special care
when being built.
- An application might need a mechanism for building complex objects that is independent
from the ones that make up the object.
- If this is the problem you are being confronted with, you might want to try using the
Builder (or Adaptive Builder) design pattern.
- This pattern allows a client object to construct a complex object by specifying only its
type and content, being shielded from the details related to the objects representation.
- This way the construction process can be used to create different representations.
- The logic of this process is isolated form the actual steps used in creating the complex
object, so the process can be used again to create a different object form the same set
of simple objects as the first one.
Applicability :
- Use the Builder pattern when
o The algorithm for creating a complex object should be independent of the
parts that make up the object and how they're assembled.
o The construction process must allow different representations for the
object that's constructed.
Structure :

13. Collaboration :
- The client creates the Director object and configures it with the desired Builder object.
- Director notifies the builder whenever a part of the product should be built.
- Builder handles requests from the director and adds parts to the product.
- The client retrieves the product from the builder.
Consequences :
- Here are key consequences of the Builder pattern:
1. It lets you vary a product's internal representation.
2. It isolates code for construction and representation.
3. It gives you finer control over the construction process.
Implementation :
- We have considered a business case of fast-food restaurant where a typical meal could
be a burger and a cold drink.
- Burger could be either a Veg Burger or Chicken Burger and will be packed by a wrapper.
Cold drink could be either a coke or pepsi and will be packed in a bottle.
- We are going to create an Item interface representing food items such as burgers and
cold drinks and concrete classes implementing the Item interface and a Packing interface
representing packaging of food items and concrete classes implementing the Packing
interface as burger would be packed in wrapper and cold drink would be packed as bottle.
- We then create a Meal class having ArrayList of Item and a MealBuilder to build different
types of Meal objects by combining Item. BuilderPatternDemo, our demo class, will use
MealBuilder to build a Meal.
Sample Code :
1 class TourAgent
2 {
3 TourBuilder builder;
4 public TourAgent(TourBuilder b)
5 {
6 builder = b;
7 }
8 public void BuildTour()
9 {
10 builder.BookHotel();
11 builder.BookRestaurant();
12 builder.BookTickets();
13 builder.BookExtras();
14 } 15 }

14. Know Users :
- StringBuilder classes in Java & C# are examples of builders that build a string in steps.
- In C++, std::string can be used to build a string through += operator or append member
function.
Related Patterns:
- Abstract Factory may also build a complex object (from a family) but it returns the
instance immediately. Builder pattern focuses on constructing a complex object step by
step.
- Builders usually build a Composite.
Advantages :
- The directorcreatesthe products throughan abstract interface.Thismakesitpossible tocreate
newkindof objectsthroughthe same constructionprocess.
- Differentrenditionsof the productscanbe constructedbyaddingdifferentdirectors.For
example,we canaddan InternationalTourAgenttobookinternational tours.
- The constructionprocesscan be controlledbecause the objectisconstructedinstepsbythe
director.Thus,ithas a finercontrol overthe constructionprocess,unlike othercreational
patterns,whichreturnanobjectin one shot.
Disadvantages :
- Clientsmayrequire more domainknowledgeforconstructingobjects(unlike factories).
When to use :
- Use whenyouwanthave a finercontrol overthe constructionprocessof an object.
- buildanobjectinsteps.
Factory Method Pattern
Intent :
- Define an interface for creating an object, but let subclasses decide which class to
instantiate. Factory method lets class defer instantiation to subclasses
Also known as:
Motivation :
- Frameworks use abstract classes to define and maintain relationships between
objects. A framework is often responsible for creating these objects as well.
Applicability :
- Use the Factory Method pattern when
1· a class can't anticipate the class of objects it must create.
2· a class wants its subclasses to specify the objects it creates.
3· classes delegate responsibility to one of several helper subclasses, and
you want to localize the knowledge of which helper subclass is the delegate.
Collaboration :
- Creator relies on its subclasses to define the factory method so that it
returns an instance of the appropriate ConcreteProduct.

15. Structure :
Consequences :
- Factory methods eliminate the need to bind application-specific classes into your
code. The code only deals with the Product interface; therefore it can work with
any user-defined ConcreteProduct classes.
- A potential disadvantage of factory methods is that clients might have to subclass
the Creator class just to create a particular ConcreteProduct object. Subclassing
is fine when the client has to subclass the Creator class anyway, but otherwise
the client now must deal with another point of evolution.
Implementation :
- Consider the following
- We're going to create a Shape interface and concrete classes implementing
the Shape interface. A factory class ShapeFactory is defined as a next step.
- FactoryPatternDemo, our demo class will use ShapeFactory to get a Shape object. It will
pass information (CIRCLE / RECTANGLE / SQUARE) to ShapeFactory to get the type
of object it needs.
Sample Code :
1//C#
2 class Controller
3 {
4 Document document;
5 public void Initialize()
6 {
7 //document=new TextDocument() ;
8 document = docFactory.Create();
9 document.Open();
10 }
11 //Rest of the class
12 }
Know Users :
- Mostly used in toolkits & frameworks.
- COM contains an interface IClassFactory that has a factory method called
CreateInstance().
- In C#, the Array class implements a static factory called CreateInstance().
- Java has LogManager.getLogManager(), Calendar.getInstance(),etc, that use the factory
method to create the instance of the respective class.

16. Related Patterns:
- Factory Method has a lot of variations. It can return a new object or the same instance
multiple times, or can return a subclass object by extending a new class.
- Factory Method is usually called through a Template Method and is usually a hook that
subclasses can override for custom implementation. E.g. override the Factory method
and provide a different implementation.
- Used to implement Abstract Factory.
- It is a flexible replacement for new as it encapsulates creation.
- Factory Method has to be subclasses if it has to return a new object. Prototypes don’t
require a new class; it requires a new object.
- Prototypes require initialize operations after returning an instance; Factory Methods
don’t require such operation.
Advantages :
- Promotes loose coupling between the client & the classes it uses.
o No need to depend on the concrete classes
- Encapsulates creation.
o Control creation
- Behaves like a virtual constructor.
o Instance is created virtually. The client doesn't know which instance it gets.
- May not create a new object upon each invocation.
o Objects can be cached for performance and reused
Disadvantages :
- A corresponding factory class is required for each concrete class.
o Leads to a large number of classes in an application
When to use :
- When the client doesn't know which class it may require at runtime.
- A class wants its subclasses to specify the objects it creates.
- You want to encapsulate creation of objects.
- Object instance needs to be initialized with some data not available to the client.
- Object instantiation requires lot of data and there are lots of variations based on the
data. Instead provide static Factory methods that create the instances based on different
variations.
Prototype Pattern
Intent :
Also known as:
Motivation :
Applicability :
Structure :
Collaboration :
Consequences :
Implementation :
Sample Code :
Know Users :

17. Related Patterns:
Advantages :
Disadvantages :
When to use :
Singleton Pattern
Intent :
Also known as:
Motivation :
Applicability :
Structure :
Collaboration :
Consequences :
Implementation :
Sample Code :
Know Users :
Related Patterns:
Advantages :
Disadvantages :
When to use :
Creational Patterns
Intent :
Also known as:
Motivation :
Applicability :
Structure :
Collaboration :
Consequences :
Implementation :
Sample Code :
Know Users :
Related Patterns:
Advantages :
Disadvantages :
When to use :

18. Shubham Narkhede 6th
Semester CSE, Design Pstterns
UNIT – 3
Structural Patterns
Adapter Patterns
Intent :
Also known as:
Motivation :
Applicability :
Structure :
Collaboration :
Consequences :
Implementation :
Sample Code :
Know Users :
Related Patterns:
Advantages :
Disadvantages :
When to use :
Bridge Patterns
Intent :
Also known as:
Motivation :
Applicability :
Structure :
Collaboration :

19. Consequences :
Implementation :
Sample Code :
Know Users :
Related Patterns:
Advantages :
Disadvantages :
When to use :
Composite Patterns
Intent :
Also known as:
Motivation :
Applicability :
Structure :
Collaboration :
Consequences :
Implementation :
Sample Code :
Know Users :
Related Patterns:
Advantages :
Disadvantages :
When to use :
Decorator Patterns
Intent :
Also known as:
Motivation :
Applicability :
Structure :
Collaboration :
Consequences :
Implementation :
Sample Code :
Know Users :
Related Patterns:
Advantages :
Disadvantages :
When to use :

20. Facade Patterns
Intent :
Also known as:
Motivation :
Applicability :
Structure :
Collaboration :
Consequences :
Implementation :
Sample Code :
Know Users :
Related Patterns:
Advantages :
Disadvantages :
When to use :
Flyweight Patterns
Intent :
Also known as:
Motivation :
Applicability :
Structure :
Collaboration :
Consequences :
Implementation :
Sample Code :
Know Users :
Related Patterns:
Advantages :
Disadvantages :
When to use :
Proxy Patterns
Intent :
Also known as:
Motivation :
Applicability :

21. Structure :
Collaboration :
Consequences :
Implementation :
Sample Code :
Know Users :
Related Patterns:
Advantages :
Disadvantages :
When to use :
Discussion of Structural Patterns
Intent :
Also known as:
Motivation :
Applicability :
Structure :
Collaboration :
Consequences :
Implementation :
Sample Code :
Know Users :
Related Patterns:
Advantages :
Disadvantages :
When to use :
Shubham Narkhede 6th
Semester CSE, Design Pstterns
UNIT – 4

22. Behavioral Patterns
Chain of Responsibility Patterns
Intent :
Also known as:
Motivation :
Applicability :
Structure :
Collaboration :
Consequences :
Implementation :
Sample Code :
Know Users :
Related Patterns:
Advantages :
Disadvantages :
When to use :
Command Patterns
Intent :
Also known as:
Motivation :
Applicability :
Structure :
Collaboration :
Consequences :
Implementation :
Sample Code :
Know Users :
Related Patterns:
Advantages :
Disadvantages :
When to use :
Interpreter Patterns

23. Intent :
Also known as:
Motivation :
Applicability :
Structure :
Collaboration :
Consequences :
Implementation :
Sample Code :
Know Users :
Related Patterns:
Advantages :
Disadvantages :
When to use :
Iterator Patterns
Intent :
Also known as:
Motivation :
Applicability :
Structure :
Collaboration :
Consequences :
Implementation :
Sample Code :
Know Users :
Related Patterns:
Advantages :
Disadvantages :
When to use :
Mediator Patterns
Intent :
Also known as:
Motivation :
Applicability :
Structure :

24. Collaboration :
Consequences :
Implementation :
Sample Code :
Know Users :
Related Patterns:
Advantages :
Disadvantages :
When to use :
Momento Patterns
Intent :
Also known as:
Motivation :
Applicability :
Structure :
Collaboration :
Consequences :
Implementation :
Sample Code :
Know Users :
Related Patterns:
Advantages :
Disadvantages :
When to use :
Observer Patterns
Intent :
Also known as:
Motivation :
Applicability :
Structure :
Collaboration :
Consequences :
Implementation :
Sample Code :
Know Users :
Related Patterns:

25. Advantages :
Disadvantages :
When to use :
State Patterns
Intent :
Also known as:
Motivation :
Applicability :
Structure :
Collaboration :
Consequences :
Implementation :
Sample Code :
Know Users :
Related Patterns:
Advantages :
Disadvantages :
When to use :
Strategy Patterns
Intent :
Also known as:
Motivation :
Applicability :
Structure :
Collaboration :
Consequences :
Implementation :
Sample Code :
Know Users :
Related Patterns:
Advantages :
Disadvantages :
When to use :

26. Template Method Patterns
Intent :
Also known as:
Motivation :
Applicability :
Structure :
Collaboration :
Consequences :
Implementation :
Sample Code :
Know Users :
Related Patterns:
Advantages :
Disadvantages :
When to use :
Visitor Patterns
Intent :
Also known as:
Motivation :
Applicability :
Structure :
Collaboration :
Consequences :
Implementation :
Sample Code :
Know Users :
Related Patterns:
Advantages :
Disadvantages :
When to use :
Discussion of Behavioral Patterns
Intent :
Also known as:
Motivation :
Applicability :

27. Structure :
Collaboration :
Consequences :
Implementation :
Sample Code :
Know Users :
Related Patterns:
Advantages :
Disadvantages :
When to use :
Shubham Narkhede 6th
Semester CSE, Design Pstterns
UNIT – 5
A Case Study
Chain of Responsibility Patterns
Intent :
Also known as:
Motivation :
Applicability :
Structure :
Collaboration :
Consequences :
Implementation :
Sample Code :
Know Users :
Related Patterns:
Advantages :
Disadvantages :
When to use :