NET Design Patterns Guide

.NET – DESIGN PATTERN
VERSION (1.0)
MOUDLE NAME
.Net DESIGN PATTERN
SUBMITTED FOR
Saudi Post
SUBMITTED BY
ARCOM

.NET – DESIGN PATTERNS
‫السعودي‬ ‫البريد‬
.NET – DESIGN PATTERN Page | 2
1. TABLE OF CONTENT
1. TABLE OF CONTENT ...................................................................................................................2
2. REVIEW HISTORY .......................................................................................................................4
2.1. STATUS ..........................................................................................................................................4
2.2. CHANGE HISTORY..........................................................................................................................4
2.3. DISTRIBUTION ...............................................................................................................................5
3. DOCUMENT PURPOSE................................................................................................................6
4. OBJECT-ORIENTED DESIGN PATTERNS .......................................................................................7
5. BASIC ELEMENTS OF A DESIGN PATTERN ...................................................................................8
6. DESIGN PATTERN STYLE GUIDE ..................................................................................................9
7. DESIGN PATTERN TYPES...........................................................................................................10
7.1. CREATIONAL PATTERNS...........................................................................................................11
7.1.1. ABSTRACT FACTORY PATTERN...............................................................................................12
7.1.2. FACTORY METHOD PATTERN.................................................................................................14
7.1.3. BUILDER PATTERN .................................................................................................................16
7.1.4. PROTOTYPE PATTERN............................................................................................................18
7.1.5. SINGLETON PATTERN.............................................................................................................20
7.2. STRUCTURE PATTERNS.............................................................................................................22
7.2.1. FACADE PATTERN ..................................................................................................................23
7.2.2. ADAPTER PATTERN................................................................................................................25
7.2.3. COMPOSITE PATTERN............................................................................................................27
7.2.4. BRIDGE PATTERN...................................................................................................................29
7.2.5. DECORATOR PATTERN...........................................................................................................31
7.2.6. FLYWEIGHT PATTERN ............................................................................................................33
7.2.7. PROXY PATTERN ....................................................................................................................36
4.3. BEHAVIOUR PATTERNS ............................................................................................................39
4.3.1. COMMAND PATTERN ............................................................................................................40
4.3.2. CHAIN OF RESPONSIBILITES PATTERN...................................................................................42
4.3.3. INTERPRETER PATTERN .........................................................................................................44
4.3.4. ITERATOR PATTERN ...............................................................................................................46
4.3.5. MEDIATOR PATTERN .............................................................................................................48
4.3.6. MOMENTO PATTERN.............................................................................................................50
4.3.7. NULL OBJECT PATTERN..........................................................................................................52
4.3.8. OBSERVER PATTERN ..............................................................................................................54

4.3.9. STATE PATTERN .....................................................................................................................56
4.3.10. STRATEGY PATTERN...............................................................................................................58
4.3.11. TEMPLATE METHOD PATTERN ..............................................................................................60
4.3.12. VISITOR PATTERN ..................................................................................................................62

2. REVIEW HISTORY
2.1.STATUS
Version 1.0
Status Proposed
2.2.CHANGE HISTORY
Date Author Version Change Reference
10/03/2016 Mohamed Zakarya 1.0 First draft

2.3.DISTRIBUTION
APPROVERS
Stakeholder Name
CONSULTED
Stakeholder Name
INFORMED
Stakeholder Name
Choose an item.
Choose an item.

3. DOCUMENT PURPOSE
As we build more complex computer systems, we face problems of construction rather
than problems of analysis. The problems of construction are solved by designing
programming solutions for such problems in the context of the computer application
we are trying to build.
Some constructional problems occur over and over again across a wide range of
different computer applications. Obviously, we can design a generic solution to such
repeating problems, and then try to adjust such a generic solution to the specific need
of the application we are currently building. Such generic solutions are usually referred
to as design patterns.
Christopher Alexander first introduced patterns to encode knowledge and experience
in designing buildings. He said: “Each pattern describes a problem which occurs over
and over again in our environment, and then describes the core of the solution to that
problem in such a way that you can use this solution many times over, without ever
doing it the same way twice”.
Thus, a design pattern is the core of a solution to a problem in context. The solution
can be applied in different situations, and has to be adapted to fit the needs of the
specific situation.

4. Object-Oriented Design Patterns
Design patterns in programming were first introduced by the Gang of Four (Gamma,
Helm, Johnson, Vlissides). They referred to design patterns always as to object-oriented
design patterns, i.e., design patterns that occur in building object-oriented computer
systems.
Thus, object-oriented design patterns might be defined as descriptions of
communicating objects and classes that are customized to solve a general (object-
oriented) design problem in a particular context.
They also stated that an object-oriented design pattern is not:
 A primitive building block, such as linked lists, or hash-tables that can be
encoded in classes and reused in a wide range of applications
 A complex, domain specific design for an entire application or subsystem.
Rather, an object-oriented design pattern just describes a recurring object-
oriented design structure.
Thus, an object-oriented design pattern:
 Names, abstracts, and identifies the key aspect (classes, objects and their
relations) of a common design structure
 Creates a reusable object-oriented design
 Focuses on a particular object-oriented design by describing when it applies,
whether it can be applying in view of other design constraints, and the
consequences and trade-offs of its use
 Implements the design idea in an object-oriented programming language.
In the rest of this paper we will examine solely object-oriented design patterns. Thus,
whenever we say a design pattern we actually refer to an object-oriented design patter

5. Basic Elements of a Design Pattern
Each pattern has four essential elements:
 The pattern name is a handle we can use to describe a design problem, its
solutions and consequences in a word or two. Naming a pattern immediately
increases the design vocabulary of programmers. Having a vocabulary for
patterns enables to talk about patterns with other programmers, in the
documentation, etc.
 The problem describes when to apply the pattern. It explains the problem and
its context. It might describe specific design problems such as how to represent
algorithms as objects. It might describe class or object structures that are
symptomatic of an inflexible design. Sometimes the problem includes also a list
of conditions that must be met before it makes sense to apply the pattern.
 The solution describes the elements that make up the design, their
relationships, responsibilities, and collaborations. The solution doesn’t describe
a particular concrete design or implementation, because a pattern is like a
template that can be applied in many different situations. Instead, the pattern
provides an abstract description of a design problem and how a general
arrangement of elements (classes and objects) solves it.
 The consequences are the results and trade-offs of applying the pattern. They
may address language and implementation issues as well. Since reuse is often
a factor in object-oriented design, the consequences of a pattern include its
impact on a system’s flexibility, extensibility, or portability.

6. DESIGN PATTERN STYLE GUIDE
The description of any pattern will follow the next style guide:
1. OVERVIEW
 Overview about the pattern
2. WHEN TO USE
 What problem you face and when to user this pattern
3. STRUCTURE
 Pattern structure
4. CHECK LIST
 Check list when implement the pattern
5. CONCEPTUAL EXAMPLE
 Real example of using pattern

7. DESIGN PATTERN TYPES
There is basic pattern that are foundation of other patterns
they are categorized in three groups
1. Creational patterns
2. Structural patterns
3. Behavioural patterns
CREATIONAL PATTERNS
 create objects for you, rather than having you instantiate objects directly.
 This gives your program more flexibility in deciding which objects need to be created
for a given case.
STRUCTURE PATTERNS
 These concern class and object composition.
 Identifying a simple way to realize relationships between entities.
 They use inheritance to compose interfaces and define ways to compose objects to
obtain new functionality.
BEHAVIOUR PATTERNS
 Identify common communication patterns between objects and realize these patterns.
 These patterns increase flexibility in carrying out this communication.

7.1. CREATIONAL PATTERNS
Creational design patterns are design patterns that deal with object creation
mechanisms, trying to create objects in a manner suitable to the situation
There are basic 6 pattern for creational pattern as follows
PATTERN DESCRIPTION Freq.
of use
Abstract factory Creates an instance of several families of classes 5/5
Factory Method Creates an instance of several derived classes 5/5
Builder Separates object construction from its representation 2/5
Prototype A fully initialized instance to be copied or cloned 3/5
Singleton A class of which only a single instance can exist 4/5

7.1.1.ABSTRACT FACTORY PATTERN
1. OVERVIEW
 Abstract Factory pattern is a super factory which creates other factories, this
factory is called factory of factories
 This pattern provides one of the best ways to create an object
 Abstract Factory pattern an interface is responsible for encapsulate a group of
individual factories that have a common theme without specifying their
concrete classes
2. WHEN TO USE
 The purpose of the Abstract Factory is to provide an interface for creating
families of related objects, without specifying concrete classes
 providing data access to two different data sources
 supporting multiple platforms while keeping your code-base unified
3. STRUCTURE
Client
 Uses interfaces declared by AbstractFactory and AbstractProduct classes
 Eg. Animal World
AbstractFactory (abstract class)
 declares an interface for operations that create abstract products
 Eg. Continent Factory
ConcreteFactory (normal class)
 implements the operations to create concrete product objects
 extend the abstract factory functionality
 Eg. (AfricaFactory, AmericaFactory)

AbstractProduct (interface – abstract class)
 declares an interface for a type of product object
 Eg. (Herbivore, Carnivore)
Product (class)
 defines a product to be created by the corresponding concrete factory
 implements the AbstractProduct interface
 Eg. Wildebeest, Lion, Bison, Wolf
4. CHECK LIST
 Map out a matrix of "platforms" versus "products"
 Define a factory interface that consists of a factory method per product.
 Define a factory derived class for each platform that encapsulates all
references to the new operator
 The client should retire all references to new, and use the factory methods to
create the product objects
 Like Sub Contracting in real world, basically delegating the creation of Objects
to expert Factories
 Orders in a restaurant are received by a Kitchen, then are assigned to Special
Chefs like Chinese, Indian, Continental.
 Continent animals [abstract factory], represent [concreate factory] like Africa
animals which have [abstract product] like Carnivore animals represented by
[product] like lion

7.1.2.FACTORY METHOD PATTERN
1. OVERVIEW
 Define an interface for creating an object, but let subclasses decide which
class to instantiate.
 Factory Method lets a class defer instantiation to subclasses.
 Factory Method is to creating objects as Template Method is to implementing
an algorithm and then delegates the creation details to subclasses that are
supplied by the client
2. WHEN TO USE
 A framework needs to standardize the architectural model for a range of
applications, but allow for individual applications to define their own domain
objects and provide for their instantiation
3. STRUCTURE
Product (interface - abstract class)
 Uses defines the interface of objects the factory method creates
 Eg. Page
ConcreteProduct
 implements the Product interface
 Eg. SkillsPage, EducationPage, ExperiencePage
Creator (interface - abstract class)
 declares the factory method, which returns an object of type Product
 Creator may also define a default implementation of the factory method
that returns a default ConcreteProduct object
 may call the factory method to create a Product object.
 Eg. Document
ConcreteCreator
 overrides the factory method to return an instance of ConcreteProduct.
 Eg. Report, Resume

4. CHECK LIST
 If you have an inheritance hierarchy that exercises polymorphism, consider
adding a polymorphic creation capability by defining a static factory method
in the base class.
 Design the arguments to the factory method. What qualities or characteristics
are necessary and sufficient to identify the correct derived class to instantiate?
 Consider making all constructors private or protected.
 Injection molding process demonstrate this pattern.
 Manufacturers of plastic toys process plastic molding powder, and inject the
plastic into molds of the desired shapes.
 The class of toy (car, action figure, etc.) is determined by the mold.

7.1.3.BUILDER PATTERN
1. OVERVIEW
 Builder pattern builds a complex object using simple objects and using a step
by step approach
 separate the construction of a complex object from its representation. By
doing so the same construction process can create different representations
2. WHEN TO USE
 create the elements of a complex aggregate. The specification for the
aggregate exists on secondary storage and one of many representations
needs to be built in primary storage.
 Parse a complex representation, create one of several targets
3. STRUCTURE
Builder (interface - abstract class)
 specifies an abstract interface for creating parts of a Product object
 Eg. VehicleBuilder
ConcreteBuilder
 constructs and assembles parts of the product by implementing the
Builder interface
 defines and keeps track of the representation it creates
 provides an interface for retrieving the product
 Eg. (MotorCycleBuilder, CarBuilder, ScooterBuilder)
Director
 constructs an object using the Builder interface, use concreate builder
 Eg. Shop
Product
 represents the complex object under construction. ConcreteBuilder
builds the product's internal
 representation and defines the process by which it's assembled
 includes classes that define the constituent parts, including interfaces
for assembling the parts into the final result
 Eg. Vehicle

4. CHECK LIST
 Decide if a common input and many possible representations (or outputs) is
the problem at hand
 Encapsulate the parsing of the common input in a Director class.
 Design a standard protocol for creating all possible output representations.
Capture the steps of this protocol in a Builder interface.
 Define a Builder derived class for each target representation.
 The client calls a Director object and create a Builder object,
 The client asks the Builder to return the result
 Toy Builder build toy in construction process
[ build head – build body – build leg – build tail – build arm]
 Drink builder in construction process
[ add water – add sugar – add milk – add powder (tea, coffee)]
 Meal Builder in construction process
[main item – side item – drink – toy – Package]

7.1.4.PROTOTYPE PATTERN
1. OVERVIEW
 Specify the kinds of objects to create using a prototypical instance, and create
new objects by copying this prototype.
 Purpose to make dynamic creation easier by defining classes whose objects
can create duplicates of themselves
2. WHEN TO USE
 avoid the inherent cost of creating a new object in the standard way 'new'
keyword
 Sometimes, it becomes necessary to copy or clone an “already grown” object
rather than instantiating it and setting its values.
 Hides the complexities of making new instances from the client.
 In certain circumstances, copy an object is more efficient than creating a new
object
 Using a Prototype design pattern hides concrete product classes from the
client
3. STRUCTURE
Prototype (abstract class)
 declares an interface for cloning itself
 specifies a pure virtual clone () method
 Eg. ColorPrototype
Concrete Prototype (normal class)
 implements an operation for cloning itself
 Eg. Color
Client
 creates a new object by asking a prototype to clone itself
 Eg. ColorManager

4. CHECK LIST
 Add a clone () method to the existing "product" hierarchy.
 Design a "registry" that maintains a cache of prototypical objects. The registry
could be encapsulated in a new Factory class, or in the base class of the
"product" hierarchy.
 finds the correct prototype object, calls clone () on that object, and returns
the result.
 The client replaces all references to the new operator with calls to the factory
method.
 Cell Division process by which a parent cell divides into two or more daughter
cells. [ identical cells] Cell division usually occurs as part of a larger cell cycle.
[the cell clones itself]

7.1.5.SINGLETON PATTERN
1. OVERVIEW
 one of the most commonly used design patterns
 Ensure a class has only one instance, and provide a global point of access to it
 By having a private default constructor for the class, other classes are not
allowed to instantiate a new object of the class
 static instance class level method is used to manage the creation of the object
2. WHEN TO USE
 Application needs one, and only one, instance of an object.
 lazy initialization and global access are necessary.
 prevents memory duplication
 saves system resources
 you can be sure that there is only one flow path for a certain task or data, this
result in more controlled and secure application work flow as well as easier
debugging and maintenance
 Ownership of the single instance cannot be reasonably assigned
3. STRUCTURE
Singleton (normal class)
 Have static property instant
 Make constructor private
 method that creates a new instance of the class if one does not exist. If
an instance already exists, it simply returns a reference to that object.

4. CHECK LIST
 Define a private static attribute in the "single instance" class.
 Define a public static accessor function in the class.
 Do "lazy initialization" (creation on first use) in the accessor function.
 Define all constructors to be protected or private.
 Clients may only use the accessor function to manipulate the Singleton.
 Logger Class: provides a global logging access point in all the application
components without being necessary to create an object each time a logging
operations is performed.
 Configuration Classes: Singleton not only that we provide a global access
point, but we also keep the instance we use as a cache object
 Conceptual Teacher Example: using the Singleton pattern, there is one
Teacher and then each Student object receives a reference of that Teacher.

7.2. STRUCTURE PATTERNS
Structure patterns are design pattern than ease the design by identifying a
simple way to realize relationships between entities.
There are basic 7 pattern for structure pattern as follows
of use
Facade A single class that represents an entire subsystem 5/5
Adapter Match interfaces of different classes 4/5
Composite A tree structure of simple and composite objects 4/5
Bridge Separates an object’s interface from its implementation 3/5
Decorator Add responsibilities to objects dynamically 3/5
Flyweight A fine-grained instance used for efficient sharing 1/5
Proxy An object representing another object 4/5

7.2.1. FACADE PATTERN
1. OVERVIEW
 Provide a unified interface to a set of interfaces in a subsystem. Facade
defines a higher-level interface that makes the subsystem easier to use
 Wrap a complicated subsystem with a simpler interface.
 commonly used with object-oriented programming.
 A facade is an object that provides a simplified interface to a larger body of
code, such as a class library.
2. WHEN TO USE
 A segment of the client community needs a simplified interface to the overall
functionality of a complex subsystem
 when a system is very complex or difficult to understand because the system
has a large number of interdependent classes or its source code is unavailable
 when you need to hide the complexities of the larger system and provides a
simpler interface to the client. (hide implementation details)
 when you need an entry point to each level of layered software
3. STRUCTURE
Facade (normal class)
The facade class abstracts Packages 1, 2, and 3 from the rest of the application.
Clients
The objects are using the Facade Pattern to access resources from the Packages.

4. CHECK LIST
 Identify a simpler, unified interface for the subsystem or component.
 Design a 'wrapper' class that encapsulates the subsystem.
 The facade/wrapper captures the complexity and collaborations of the
component, and delegates to the appropriate methods.
 The client uses (is coupled to) the Facade only.
 Consider whether additional Facades would add value.
 The customer service representative acts as a Facade
 Make Pizza acts as facade represent pizza component cheese, sauce, etc.

7.2.2.ADAPTER PATTERN
1. OVERVIEW
 An adapter helps two incompatible interfaces to work together
 Allows the interface of an existing class to be used from another interface.
 It is often used to make existing classes work with others without modifying
their source code
 Interfaces may be incompatible but the inner functionality should suit the
need
2. WHEN TO USE
 An "off the shelf" component offers compelling functionality that you would
like to reuse, but its "view of the world" is not compatible with the philosophy
and architecture of the system currently being developed.
 allows incompatible classes to work together by converting the interface of
one class into an interface expected by the clients
3. STRUCTURE
Client:
Collaborates with objects conforming to the Target interface (eg. computer)
Target:
Defines the domain-specific interface that Client uses (eg. USB interface)
Adapter:
Adapts the interface Adaptee to the Target interface. (eg. PS/2 – USB adapter)
Adaptee:
Defines an existing interface that needs adapting (eg. PS/2 Mouse)

4. CHECK LIST
 Identify the players: the component(s) that want to be accommodated (i.e. the
client), and the component that needs to adapt (i.e. the adaptee).
 Identify the interface that the client requires.
 Design a "wrapper" class that can compatible the adaptee to the client.
 The adapter/wrapper class "has a" instance of the adaptee class.
 The adapter/wrapper class "maps" the client interface to the adaptee
interface.
 The client uses (is coupled to) the new interface
 Old mouse with PS/2 Port use USB adaptor to send data to computer USB
 A man speaks Arabic need English translator adaptor to speak to English man
 2 phase plug need adapter to send signal to 3 phase socket
 Sata converter in hard disk

7.2.3.COMPOSITE PATTERN
1. OVERVIEW
 Composite pattern allows you to compose objects into tree structures to
represent part-whole hierarchies
 Composite lets clients treat individual objects and compositions of objects
uniformly [same way]
 Directories contain entries, each of which could be a directory
 Composite Like Menu – menu item tree structure
2. WHEN TO USE
 Application needs to manipulate a hierarchical collection of "primitive" and
"composite" objects
 Processing of a primitive object is handled one way, and processing of a
composite object is handled differently and its needed to be uniformly
3. STRUCTURE
Component:
 The abstraction for all components, including composite ones
 Declares the interface for objects in the composition
 [Optional] defines an interface for accessing a component's parent in the
recursive structure
Leaf:
 Represents leaf objects in the composition
 Implements all Component methods
Composite:
 Represents a composite Component (component having children)
 Implements methods to manipulate children
 Implements all Component methods, generally by delegating them to its
children

4. CHECK LIST
 Ensure that your problem is about representing "whole-part" relationships.
 Divide your domain concepts into container classes, and containee classes.
"Containers that contain containees, each of which could be a container"
 Create a "lowest common denominator" [component] interface that makes
your containers and containees interchangeable. It should specify the
behaviour that needs to be exercised uniformly across all containee and
container objects.
 All container and containee declare an "is a" relationship to the interface.
 All container declares a one-to-many "has a" relationship to the interface.
 Container leverage polymorphism to delegate to their containee objects.
 Child management methods [e.g. addChild (), removeChild ()] should normally
be defined in the Composite class
 Family tree structure
 Work place organizational tree structure
 Directories tree structure files and child directories
 Menu that contain menu items, each could be menu
 Containers that contain elements, each could be containers

7.2.4.BRIDGE PATTERN
1. OVERVIEW
 Bridge decouple an abstraction from its implementation so that the two can
vary independently
 The bridge uses encapsulation, aggregation, and can use inheritance to
separate responsibilities into different classes.
 bridge pattern is often implemented using the class adapter pattern
 The bridge pattern can also be thought of as two layers of abstraction
2. WHEN TO USE
 decoupling the object's interface
 If you want to share an implementation among multiple objects
 If you want run-time binding of the implementation
 hiding details from clients
3. STRUCTURE
Abstraction (abstract class)
 defines the abstract interface
 maintains the Implementer reference.
 Eg. Shape abstract class
RefinedAbstraction (normal class)
 extends the interface defined by Abstraction
 Eg. Rectangle class
Implementor (interface)
 defines the interface for implementation classes
ImplementorA – ImplementorB (normal class)
 implements the Implementor interface
 Eg. Blue Implementer color

4. CHECK LIST
 Design a platform-oriented interface that is minimal, necessary, and sufficient.
Its goal is to decouple the abstraction from the platform
 Design the separation of concerns: what does the client want, and what do
the platforms provide
 Define a derived class of that interface for each platform
 Define specializations of the abstraction class if desired.
 The purpose of the switch is to turn a device on or off
 The actual switch can be implemented as a pull chain, simple two position
switch, or a variety of dimmer switches

7.2.5.DECORATOR PATTERN
1. OVERVIEW
 Decorator pattern Allows behaviour to be added to an individual object,
either statically or dynamically, without affecting the behaviour of other
objects from the same class

2. WHEN TO USE
 Extend (decorate) the functionality of a certain object
 add behaviour or state to individual objects at run-time
3. STRUCTURE
Component (Interface)
 Defines the interface for objects that can have responsibilities added to
them dynamically
 Have members that will implemented by ConcreteComponent and
decorator
 Eg. Ice Cream abstract
ConcreteComponent (normal class)
 Define object to be decorated object to which additional responsibilities
can be attached to component.
 Eg. Chocolate, vanilla
Decorator (abstract class)
 maintains a reference to a Component object and defines an interface that
conforms to Component's interface
 act as base class for all decorators for components
 Eg. IceCream Topping "Add-ins"

ConcreteDecorator (normal class)
 override any Component method(s) whose behavior needs to be modified
 add additional responsibilities to the component
 Eg. Caramel
4. CHECK LIST
 Ensure the context is: a single core (or non-optional) component, several
optional decoration or wrappers, and an interface that is common to all
(Concreate Component)
 Create a "Lowest Common Denominator" interface that makes all classes
interchangeable (Component)
 Create a second level base class (Decorator) to support the wrapper classes.
 The Decorator class declares a composition relationship to the Component
interface, and this data member is initialized in its constructor
 The Decorator class delegates to the Component object.
 Define a Decorator derived class for each optional embellishment. (concreate
decorator)
 Decorator derived classes implement their wrapper functionality - and -
delegate to the Decorator base class
 The client configures the type and ordering of Core and Decorator objects
 Ice cream (Component) with types like vanilla (Concrete Component) and
toppings (decorator) like caramel (Concreate decorator)
 Car (Component) with type like BMW (Concrete Component) and car
decorator can be petroleum or diesel (Concreate decorator)
 plain pizza need pizza decorator to make chicken pizza, veg pizza, etc.
 Weapon needs weapon decorator to add utilities to be advanced weapon

7.2.6.FLYWEIGHT PATTERN
1. OVERVIEW
 A flyweight is an object that minimizes memory use by sharing as much data
as possible with other similar objects
 it is a way to use objects in large numbers when a simple repeated
representation would use an unacceptable amount of memory.
 Flyweight is all about memory and sharing.
 There are two types of flyweight:
1. Intrinsic States are things that are constant and stored in the memory.
2. Extrinsic states are things that are not constant and needs to be calculated
on the fly and are therefore not stored in the memory.
2. WHEN TO USE
 Need to create large number of objects.
 Because of the large number when memory cost is a constraint.
 When most of the object attributes can be made external and shared.
3. STRUCTURE
Flyweight (Interface)
 declares an interface through which flyweights can receive and act on
extrinsic state
 Eg. Character
ConcreteFlyweight
 implements the Flyweight interface and adds storage for intrinsic state
 A ConcreteFlyweight object must be sharable
 Any state it stores must be intrinsic,
 Eg. (CharacterA, CharacterB, ..., CharacterZ)
UnsharedConcreteFlyweight
 not all Flyweight subclasses need to be shared
 The Flyweight interface enables sharing, but it doesn't enforce it
 Eg. Ice Cream abstract

FlyweightFactory
 creates and manages flyweight objects
 ensures that flyweight is shared properly.
 When a client requests a flyweight, the FlyweightFactory objects assets an
existing instance or creates one, if none exists.
 Eg. CharacterFactory
Client
 maintains a reference to flyweight(s).
 computes or stores the extrinsic state of flyweight(s).
 Eg. FlyweightApp
4. CHECK LIST
 Ensure that object overhead is an issue needing attention, and, the client of
the class is able and willing to absorb responsibility realignment.
 Divide the target class's state into: shareable (intrinsic) state, and non-
shareable (extrinsic) state
 Remove the non-shareable state from the class attributes, and add it the
calling argument list of affected methods
 Create a Factory that can cache and reuse existing class instances.
 client must use the Factory instead of the new operator to request objects.
 client must look-up or compute the non-shareable state, and supply that
state to class methods.

 Angry bird application is the better example of flyweight pattern where
shape of bird is Intrinsic state while the color of the shape is Extrinsic state
 Modern web browsers use this technique to prevent loading same images
twice. When browser loads a web page, it traverses through all images on that
page. Browser loads all new images from Internet and places them the
internal cache. For already loaded images, a flyweight object is created, which
has some unique data like position within the page, but everything else is
referenced to the cached one.

7.2.7.PROXY PATTERN
1. OVERVIEW
 Provide a delegate or placeholder for another object to control access to it.
 proxy is a wrapper or agent object that is being called by the client to access
the real serving object behind the scenes
 For the client, usage of a proxy object is similar to using the real object,
because both implement the same interface.
 In the proxy extra functionality can be provided rather than real subject like
caching or check conditions before call real subject
2. WHEN TO USE
 you do not want to instantiate such objects unless and until they are actually
requested by the client. Like [protection proxy type]
 There are four common situations in which the Proxy pattern is applicable.
1. A virtual proxy:
placeholder for "expensive to create" objects. The real object is only
created when a client first requests/accesses the object
2. A remote proxy:
provides a local representative for an object that resides in a different
address space
3. A protective proxy:
controls access to a sensitive object. The "surrogate" object checks the
caller has the access permissions required prior to forwarding the request.
4. A smart proxy:
interposes additional actions when an object is accessed like
 Counting the number of references to the real object
 Loading a persistent object into memory when it's first referenced
 Checking that the real object is locked before it is accessed to
ensure that no other object can change it
3. STRUCTURE

Proxy (normal class)
 maintains a reference that lets the proxy access the real subject.
 provides an interface identical to Subject's so that a proxy can be
substituted for the real subject
 controls access to the real subject and may be responsible for creating and
deleting it
 Eg. Proxy Server - ATM
Subject (interface - abstract class)
 defines the common interface for RealSubject and Proxy so that a Proxy
can be used anywhere a RealSubject is expected.
 Eg. Server - Bank
RealSubject (normal class)
 defines the real object that the proxy represents.
 Eg. Web Server – DB Server – Concrete Bank
4. CHECK LIST
 Identify the leverage or "aspect" that is best implemented as a wrapper or
surrogate
 Define an interface that will make the proxy and the original component
interchangeable.
 The wrapper class holds a pointer to the real class and implements the
interface.
 The pointer may be initialized at construction, or on first use.
 Each wrapper method contributes its leverage, and delegates to the wrappee
object.

 ATM Machine represent as proxy between customer who need to make
transaction and the bank [real subject]
 Proxy server in internet represent proxy between client request and
destination server
 Check represented as proxy between customer and real fund account

4.3. BEHAVIOUR PATTERNS
Behavioural design patterns are design patterns that identify common
communication patterns between objects and realize these patterns.
There are basic 12 pattern for behavioural pattern as follows
of use
Command Encapsulate a command request as an object 4/5
Chain
of responsibilities
A way of passing a request between a chain of objects 2/5
Interpreter A way to include language elements in a program 1/5
Iterator Sequentially access the elements of a collection 5/5
Mediator Defines simplified communication between classes 2/5
Memento Capture and restore an object's internal state 1/5
Null Object Designed to act as a default value of an object 4/5
Observer A way of notifying change to a number of classes 5/5
State Alter an object's behaviour when its state changes 3/5
Strategy Encapsulates an algorithm inside a class 4/5
Template Method Defer the exact steps of an algorithm to a subclass 3/5
Visitor Defines a new operation to a class without change 1/5

4.3.1. COMMAND PATTERN
1. OVERVIEW
 object is used to encapsulate all information needed to perform an action or
trigger an event at a later time
 This information includes the method name, the object that owns the method
and values for the method parameters.
 terms associated with command are command, receiver, invoker and client
 An object-oriented call-back
2. WHEN TO USE
 Need to issue requests to objects without knowing anything about the
operation being requested or the receiver of the request.
 Command objects are useful for implementing
GUI buttons and menu items Macro recording
Mobile Code Multi-level undo
Networking Progress bars
Parallel Processing Thread pools
Transactional behaviour Wizards
3. STRUCTURE
Command (normal class)
 declares an interface for executing an operation
 Eg. ICommand
ConcreteCommand (normal class)
 defines a binding between a Receiver object and an action
 implements Execute by invoke the corresponding operation(s) on Receiver
 Eg. LightOn, LightOff, AirConditionerOn, ConditionerOff
Client (normal class)
 creates a ConcreteCommand object and sets its receiver
 Eg. User
Invoker (normal class)
 asks the command to carry out the request
 Eg. RemoteController

Receiver (normal class)
 how to perform the operations associated with carrying out the request.
 Eg. AirConditioner, Light
4. CHECK LIST
 Define a Command interface with a method signature like execute ()
 Create one or more derived classes that encapsulate some subset of the
following: a "receiver" object, the method to invoke, the arguments to pass.
 Instantiate a Command object for each deferred execution request.
 Pass Command object from the creator (sender) to the invoker (receiver)
 The invoker decides when to execute ().
 The customer (client) request order from waiter (invoker) he places the order
(command) and the order send to cook (Receiver)
 Client click menu item open (invoker) this will call open (command) and this
command will execute open file (receiver).

4.3.2. CHAIN OF RESPONSIBILITES PATTERN
1. OVERVIEW
 consisting of a source of command objects and a series of processing objects
 Each processing object contains logic that defines the types of command
objects that it can handle
 The rest are passed to the next processing object in the chain
 Chain the receiving objects and pass the request along the chain until an
object handles it.
 An object-oriented linked list with recursive traversal.
2. WHEN TO USE
 There is a potentially variable number of "handler" or "processing element" or
"node" objects, and a stream of requests that must be handled. Need to
efficiently process the requests without hard-wiring handler relationships and
precedence, or request-to-handler mappings.
 receiving objects together, and then passes any request messages from
object to object until it reaches an object capable of handling the message
3. STRUCTURE
Handler (abstract class)
 defines an interface for handling the requests
 (optional) implements the successor link
 Eg. Approver
ConcreteHandler (normal class)
 handles request it is responsible for
 can access its successor
 if the ConcreteHandler can handle the request, it does so; otherwise it
forwards the request to its successor
 Eg. (Director, Vice-president, President
Client (normal class)
 initiates the request to a ConcreteHandler object on the chain
 Eg. ChainApp

4. CHECK LIST
 The base class maintains a "next" pointer.
 Each derived class implements its contribution for handling the request.
 If the request needs to be "passed on", then the derived class "calls back" to
the base class, which delegates to the "next" pointer.
 The client (or some third party) creates and links the chain (which may include
a link from the last node to the root node).
 The client "launches and leaves" each request with the root of the chain.
 Recursive delegation produces the illusion of magic.
 Question flow represent one person handle the request and answer the
question, if the first one know he won't ask the next one
 The Chain of Responsibility pattern avoids coupling the sender of a request to
the receiver by giving more than one object a chance to handle the request.
ATM use the Chain of Responsibility in money giving mechanism.

4.3.3. INTERPRETER PATTERN
1. OVERVIEW
 The interpreter design pattern provides way to evaluate language grammar or
expression. This pattern is used in sql parsing, symbol processing engine etc.
 Interpreter involves implementing an expression interface which tells to
interpret a particular context.
2. WHEN TO USE
 parsing light expressions defined in simple grammars and sometimes in
simple rule engines.
 Interpreter pattern only in terms of formal grammars but in this area there are
better solutions and this is the reason why this pattern is not so frequently
used
3. STRUCTURE
AbstractExpression (abstract class)
 Eg. Expression
TerminalExpression
 implements Interpret operation related to terminal symbols in grammar.
 an instance is required for every terminal symbol in the sentence.
 Eg. (ThousandExpression, HundredExpression, TenExpression,
OneExpression)
NonterminalExpression
 defines an interface for handling the requests
 (optional) implements the successor link
 Eg. Approver
Context
 contains information that is global to the interpreter
 Eg. Context

Client
 builds an abstract syntax tree representing a particular sentence in the
language that the grammar defines, this will be assembled from instances
of the NonterminalExpression and TerminalExpression classes
 invokes the Interpret operation
 Eg. InterperterApp
4. CHECK LIST
 Decide if a "little language" offers a justifiable return on investment.
 Define a grammar for the language.
 Map each production in the grammar to a class.
 Organize the suite of classes into the structure of the Composite pattern.
 Define an interpret(Context) method in the Composite hierarchy.
 Context object encapsulates the current state of the input and output as the
former is parsed and the latter is accumulated. It is manipulated by each
grammar class as the "interpreting" process transforms input into output.
 Date interpreter in have multiple date expression and it can receive logic date
context format and interpret it to readable format
 Google translate is example of interpreter it read the input language and
interpreted into other language
 Musicians are examples of Interpreters. Tone of a sound and its duration can
be represented in musical notation on a staff. This notation provides the
language of music. Musicians playing the music from the score are able to
reproduce the original tone and duration of each sound represented.

4.3.4. ITERATOR PATTERN
1. OVERVIEW
 The iterator pattern is a design pattern in which an iterator is used to traverse a
container and access the container's elements
 Provide a way to access the elements of an aggregate object sequentially without
exposing its underlying representation.
 .NET Framework has special interfaces that support a simple iteration:
[System.Collections.IEnumerator] over a non-generic collection and
System.Collections. Generic.IEnumerator<T> over a generic collection.

2. WHEN TO USE
 Need to "abstract" the traversal of wildly different data structures so that algorithms
can be defined that are capable of interfacing with each transparently.
1. STRUCTURE
Iterator (abstract class – interface)
 defines an interface for accessing and traversing elements.
 Has abstract Traversing operation (first, next, isDone, currentitem)
 Eg. Iterator
ConcreteIterator
 implements the Iterator interface.
 keeps track of the current position in the traversal of the aggregate.
 Eg. FacebookIterator – TwitterIterator both represent iterator
Aggregate (abstract class – interface)
 defines an interface for creating an Iterator object
 Eg. ISocialNetorking
ConcreteAggregate
 implements the Iterator creation interface to return an instance of the proper
ConcreteIterator

 Eg. Facebook (include user array), twitter (include user linkedlist)
2. CHECK LIST
 Add a create_iterator () method to the "collection" class, and grant the
"iterator" class privileged access.
 Design an "iterator" class that can encapsulate traversal of the "collection"
class.
 Clients ask the collection object to create an iterator object.
 Clients use the first (), is_done (), next (), andcurrent_item () protocol to access
the elements of the collection class.
 In office settings where access to files is made through administrative or
secretarial staff, the Iterator pattern is demonstrated with the secretary acting
as the Iterator, To the executive, the filing system is confusing and illogical,
but the secretary is able to access files quickly and efficiently.
 On early television sets, a dial was used to change channels. When channel
surfing, the viewer was required to move the dial through each channel
position, regardless of whether or not that channel had reception.
On modern television sets, a next and previous button are used. When the
viewer selects the "next" button, the next tuned channel will be displayed

4.3.5. MEDIATOR PATTERN
1. OVERVIEW
 The mediator is the communication centre of the objects.
 When an object needs to communicate to another object, it doesn’t call the
other object directly. Instead it calls the mediator object which is to route the
communication to the destination object.
 Ensures that the components are loosely coupled, such that they don't call
each other explicitly; rather they always use a separate Mediator
implementation to do those jobs
2. WHEN TO USE
 reduce communication complexity between multiple objects or classes
 design reusable components, organize dependency between reusable pieces
and avoid spaghetti code
 reduce coupling between objects
3. STRUCTURE
Mediator (abstract class - interface)
 Defines an interface for communicating with Colleague objects
 Eg. IChatRoom
Concrete Mediator
 implements cooperative behaviour by coordinating Colleague objects
 knows and maintains its colleagues
 Eg. Chatroom
Colleague classes
 each Colleague class knows its Mediator object
 each colleague communicates with its mediator whenever it would have
otherwise communicated with another colleague
 Eg. Participant

4. CHECK LIST
 Identify a collection of interacting objects that would benefit from mutual
decoupling.
 Encapsulate those interactions in the abstraction of a new class.
 Create an instance of that new class and rework all "peer" objects to interact
with the Mediator only.
 Balance the principle of decoupling with the principle of distributing
responsibility evenly.
 Be careful not to create a "controller" object.
 Chat room represent mediator between people need to contact to each other
 Facebook group represent mediator between users join it if anything updated
it will route to all registered users
 In Air Traffic Control (ATC) mediator, the pilots of the planes approaching or
departing the terminal area communicate with the tower rather than explicitly
communicating with one another
 The constraints on who can take off or land are enforced by the tower.
 It is important to note that the tower does not control the whole flight. It
exists only to enforce constraints in the terminal area.

4.3.6. MOMENTO PATTERN
1. OVERVIEW
 The Memento captures and externalizes an object's internal state so that the
object can later be restored to that state
2. WHEN TO USE
 Need to restore an object back to its previous state (e.g. "undo" or "rollback"
operations).
3. STRUCTURE
Memento (abstract class - interface)
 Defines an interface for communicating with Colleague objects
 the lock box that is written and read by the Originator, and derived by the
Caretaker
 Eg. Memento
Originator
 creates a memento containing a snapshot of its current internal state.
 uses the memento to restore its internal state
 the object that knows how to save itself.
 Eg. Sales Prospect
Caretaker
 is responsible for the memento's safekeeping
 never operates on or examines the contents of a memento.
 the object that knows why and when the Originator needs to save and restore
itself.
 Eg. Caretaker

4. CHECK LIST
 Identify the roles of “caretaker” and “originator”.
 Create a Memento class and declare the originator a friend.
 Caretaker knows when to "check point" the originator.
 Originator creates a Memento and copies its state to that Memento.
 Caretaker holds on to (but cannot peek into) the Memento.
 Caretaker knows when to "roll back" the originator.
 Originator reinstates itself using the saved state in the Memento.
 Mechanics repairing drum brakes on their cars. The drums are removed from
both sides, exposing both the right and left brakes.
 Only one side is disassembled and the other serves as a Memento of how the
brake parts fit together.
 Only after the job has been completed on one side is the other side
disassembled.
 When the second side is disassembled, the first side acts as the Memento.

4.3.7. NULL OBJECT PATTERN
1. OVERVIEW
 Null Object is an object with no referenced value or with defined neutral
("null") behaviour.
 The Null Object design pattern describes the uses of such objects and their
behaviour
2. WHEN TO USE
references may be null. These references need to be checked to ensure they are
not null before invoking any methods, because methods typically cannot be
invoked on null references
3. STRUCTURE
Client
AbstractObject
 declares the interface for Client's collaborator
 implements default behaviour for the interface common to all classes, as
appropriate
RealObject
 defines a concrete subclass of AbstractObject whose instances provide useful
behaviour that Client expects
NullObject
 provides an interface identical to Abstract Object's so that a null object can be
substituted for a real object
 implements its interface to do nothing What exactly it means to do nothing
depends on what sort of behaviour Client is expecting
 when there is more than one way to do nothing, more than one NullObject
class may be required

4. CHECK LIST
 Create abstract class that defines the interface for all objects of this type
 Create Null Object is implemented as a subclass of this abstract class
 N/A

4.3.8. OBSERVER PATTERN
1. OVERVIEW
 Define a one-to-many dependency between objects so that when one object
changes state, all its dependents are notified and updated automatically.
 Observer pattern is also a key part in the familiar model–view–controller
(MVC) architectural pattern
2. WHEN TO USE
 the change of a state in one object must be reflected in another object
without keeping the objects tight coupled.
 the framework we are writing needs to be enhanced in future with new
observers with minimal changes.
3. STRUCTURE
Subject
 Any number of Observer objects may observe a subject
 provides an interface for attaching and detaching Observer objects.
 Eg. Stock
Concrete Subject
 stores state of interest to Concrete Observer
 sends a notification to its observers when its state changes
 Eg. IBM
Observer
 Defines an updating interface for objects that should be notified of changes
in a subject.
 Eg. IInvestor
Concrete Observer
 maintains a reference to a Concrete Subject object
 stores state that should stay consistent with the subject's

 implements the Observer updating interface to keep its state consistent with
the subject's
 Eg. Investor
4. CHECK LIST
 Differentiate between the core (or independent) functionality and the optional
(or dependent) functionality.
 Model the independent functionality with a "subject" abstraction.
 Model the dependent functionality with an "observer" hierarchy.
 The Subject is coupled only to the Observer base class.
 The client configures the number and type of Observers.
 Observers register themselves with the Subject.
 The Subject broadcasts events to all registered Observers.
 The Subject may "push" information at the Observers, or, the Observers may
"pull" the information they need from the Subject
 Example 1: News Agency
 A news agency gathers news and publish them to different subscribers.
 We need to create a framework for and agency to be able to inform
immediately, when event occurs, its subscribers about the event.
 The subscribers can receive the news in different ways: Emails, SMS
 Example 2: Some auctions
 Each bidder possesses a numbered paddle that is used to indicate a bid.
 The auctioneer starts the bidding, and "observes" when a paddle is raised
to accept the bid.
 The acceptance of the bid changes the bid price which is broadcast to all
of the bidders in the form of a new bid.

4.3.9. STATE PATTERN
1. OVERVIEW
 Allow an object to alter its behaviour when its internal state changes
 known as the objects for states pattern
 The object will appear to change its class.
 An object-oriented state machine
2. WHEN TO USE
 encapsulate varying behaviour for the same object based on its internal state.
 a cleaner way for object to change its behaviour at runtime without resorting
to large solid conditional statements and thus improve maintainability
3. STRUCTURE
Context
 defines the interface of interest to clients
 maintains instance of a ConcreteState subclass to defines the current state.
 Eg. Account
state (interface – abstract class)
 defines an interface for encapsulating the behavior associated with a
particular state of the Context.
 Eg. State
ConcreteState
 each subclass implements a behavior associated with a state of Context
 Eg. (RedState, SilverState, GoldState)

4. CHECK LIST
 Identify an existing class, or new class, that will serve as the "state machine"
from the client's perspective. That class is the "wrapper" class.
 Create a State base class that replicates the methods of the state machine
interface. Each method takes one additional parameter: an instance of the
wrapper class. The State base class specifies any useful "default" behavior.
 Create a State derived class for each domain state. These derived classes only
override the methods they need to override.
 The wrapper class maintains a "current" State object.
 All client requests to the wrapper class are simply delegated to the current
State object, and the wrapper object's this pointer is passed.
 The State methods change the "current" state in the wrapper object as
appropriate.
 ATM has states like [no debit card] state and you can only insert card and
[has debit card] state you can do other multiple operations
 SLDC (software development lifecycle) are states of any application from
requirement to maintenance
 TV Remote control has states on, off and each state has set of operations
 Vending Machine has multiple status like [money not inserted, product not
selected] and [money inserted and product selected]

4.3.10. STRATEGY PATTERN
1. OVERVIEW
 Define a family of algorithms, encapsulate each one, and make them
interchangeable
 Strategy lets the algorithm vary independently from the clients that use it.
 Capture the abstraction in an interface, bury implementation details in derived
classes.
2. WHEN TO USE
 Help to activate [open-closed principle] should be open for extension, but
closed for modification
 If your system needs to dynamically select one of several algorithms.
 If your system in which there are many classes, then if you need dynamically
allows to choose a behavior use the strategy pattern
3. STRUCTURE
Context
 is configured with a ConcreteStrategy object
 maintains a reference to a Strategy object
 may define an interface that lets Strategy access its data.
 Eg. SortedList
Strategy (interface – abstract class)
 declares an interface common to all supported algorithms. Context uses this
interface to call the algorithm defined by a ConcreteStrategy
 Eg. Sort Strategy
ConcreteStrategy
 implements the algorithm using the Strategy interface
 Eg. (QuickSort, ShellSort, MergeSort)

4. CHECK LIST
 Identify an algorithm (i.e. a behavior) that the client would prefer to access
through a "flex point".
 Specify the signature for that algorithm in an interface.
 Bury the alternative implementation details in derived classes.
 Clients of the algorithm couple themselves to the interface.
 Compress files may be done by two strategy compress using zip or using rar
then send result to client
 When customer purchase something from mall, he can choose to pay using
different strategies like credit cards, debit cards or cache
 When client need to go to airport he can choose from different transport
strategies like taxi, bus, metro, etc.

4.3.11. TEMPLATE METHOD PATTERN
1. OVERVIEW
 defines the program skeleton of an algorithm in a method
 let one redefine certain steps of an algorithm without changing the
algorithm's structure
 Base class declares algorithm 'placeholders', and derived classes implement
the placeholders.
 Base class is created that provides the basic steps of an algorithm design.
These steps are implemented using abstract methods. Later on, subclasses
change the abstract methods to implement real actions.
2. WHEN TO USE
 used in frameworks, where each implements the invariant parts of a domain's
architecture, leaving "placeholders" for customisation options
 Let subclasses implement (through method overriding) behavior that can vary
 Avoid duplication in the code
 Control at what point(s) sub classing is allowed
3. STRUCTURE
AbstractClass (interface – abstract class)
 defines abstract primitive operations that concrete subclasses define to
implement steps of an algorithm
 implements a template method defining the skeleton of an algorithm.
 The template method calls primitive operations as well as operations defined
in AbstractClass or those of other objects.
 Eg. DataObject
ConcreteClass
 implements the primitive operations to carry out subclass-specific steps of the
algorithm
 Eg. CustomerDataObject

4. CHECK LIST
 Examine the algorithm, and decide which steps are standard and which steps
are peculiar to each of the current classes.
 Define a new abstract base class to host the "don't call us, we'll call you"
framework.
 Move the shell of the algorithm (now called the "template method") and the
definition of all standard steps to the new base class.
 Define a placeholder or "hook" method in the base class for each step that
requires many different implementations. This method can host a default
implementation
 Invoke the hook method(s) from the template method.
 Each of the existing classes declares an "is-a" relationship to the new abstract
base class.
 Remove from the existing classes all the implementation details that have
been moved to the base class.
 The only details that will remain in the existing classes will be the
implementation details peculiar to each derived class.
 Home builders use the Template Method when developing a new subdivision
 A typical subdivision consists of a limited number of floor plans with different
variations available for each
 Within a floor plan, the foundation, framing, plumbing, and wiring will be
identical for each house
 Other example is daily routine of a worker.

4.3.12. VISITOR PATTERN
1. OVERVIEW
 visitor design pattern is a way of separating an algorithm from an object
structure on which it operates.
 A practical result of this separation is the ability to add new operations to
existing object structures without modifying those structures.
 one way to follow the open/closed principle.
2. WHEN TO USE
 Similar operations have to be performed on objects of different types
grouped in a structure (a collection or a more complex structure).
 There are many distinct and unrelated operations needed to be performed.
Visitor pattern allows us to create a separate visitor concrete class for each
operation type and to separate operation implementation from the objects
structure.
 The object structure is not likely to be changed but is very probable to have
new operations which have to be added.
 Since the pattern separates the visitor (representing operations, algorithms,
behaviours) from the object structure it's very easy to add new visitors as long
as the structure remains unchanged.
3. STRUCTURE
Visitor (Visitor)
 declares a Visit operation for each class of concreteElement in object structure
 The operation's name and signature identifies the class that sends the Visit
request to the visitor That lets the visitor determine the concrete class of the
element being visited.
 Then the visitor can access the elements directly using its particular interface
 Eg. Visitor

ConcreteVisitor
 implements each operation declared by Visitor.
 Each operation implements a fragment of the algorithm defined for the
corresponding class or object in the structure.
 ConcreteVisitor provides the context for the algorithm and stores its local state.
 This state often accumulates results during the traversal of the structure.
 Eg. (IncomeVisitor, VacationVisitor)
Element
 defines an Accept operation that takes a visitor as an argument.
 Eg. Element
ConcreteElement
 implements an Accept operation that takes a visitor as an argument
 Eg. Employee
ObjectStructure
 can enumerate its elements
 may provide a high-level interface to allow the visitor to visit its elements
 may either be a Composite (pattern) or a collection such as a list or a set
 Eg. Employees
4. CHECK LIST
 Confirm that the current hierarchy (known as the Element hierarchy) will be
fairly stable and that the public interface of these classes is sufficient for the
access the Visitor classes will require. If these conditions are not met, then the
Visitor pattern is not a good match.
 Create a Visitor base class with a visit(ElementXxx)method for each Element
derived type.
 Add an accept(Visitor) method to the Element hierarchy. The implementation
in each Element derived class is always the same – accept (Visitor v) {v. visit
(this);}. Because of cyclic dependencies, the declaration of the Element and
Visitor classes will need to be interleaved.
 The Element hierarchy is coupled only to the Visitor base class, but the Visitor
hierarchy is coupled to each Element derived class. If the stability of the
Element hierarchy is low, and the stability of the Visitor hierarchy is high;
consider swapping the 'roles' of the two hierarchies.
 Create a Visitor derived class for each "operation" to be performed on
Element objects. visit () implementations will rely on the Element's public
interface.
 The client creates Visitor objects and passes each to Element objects by
calling accept ().

 the operation of a taxi company. When a person calls a taxi company
(accepting a visitor), the company dispatches a cab to the customer. Upon
entering the taxi, the customer, or Visitor, is no longer in control of his or her
own transportation, the taxi (driver) is.

NET Design Patterns Guide

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (6)

Similar to NET Design Patterns Guide

Similar to NET Design Patterns Guide (20)

More from Mohamed Zakarya Abdelgawad

More from Mohamed Zakarya Abdelgawad (20)

Recently uploaded

Recently uploaded (20)

NET Design Patterns Guide