DESIGN PATTERNS

What is design pattern?

A design pattern is a predefined solution to a recurring Object-Oriented design problem. The design pattern defines a relationship between collaborating interfaces, classes and Objects each with unique role that helps solve the problem.

Interface: Defines a group of property and method signatures.
Class: Defines an implementation of the interfaces it supports.

OMT: Object Modeling Techniques
UML: Unified Modeling Language

1. ADAPTER
2. BRIDGE
3. OBJECT BY VALUE
4. SMART PROXY
5. OBJECT FACTORY
6. SINGLETON
7. REPOSITORY
8. STATE
9. EVENT SERVICE
10.MVC - Model View Controller

ADAPTER

Purpose

The adapter design pattern provides a new interface to a class, Object or Function that allows it to collaborate with other objects in a given domain

Utilization

The adapter design pattern is useful in the following circumstances

1. The application’s architecture requires a specific interface, but the class you want to use is located in a compiled class library and does not support the interface. Because you don’t have to the source code for the class library, adding a new interface to an existing class via inheritance is not an option.

2. Implementing a new interface in an existing class proves to be impractical. A single class might be overloaded with the implementation of numerous interface in an attempt to improve the utility value gained by each caller

3. The functionality to support a specific interface is dispersed among many existing classes in a system. Instead of maintaining separate object references to each class instance needed, you could define a new class that expose a single interface that internally maintains references to that required class instances. Not only do you simply access to a set of objects but you also encapsulate the logic that determines which object to use when.

4. plugging in to the functionality of existing non-object-oriented legacy code make sense. It is often the case that a firm has already invested a considerable amount of time and money in developing services in legacy code. Using the adapter design pattern to reference the legacy code might be more cost effective than rewriting the code as an object – oriented solution.

5. The intention is to extend the functionality of an object without modifying its interface.

Scenario

1. To enhance the functionality of a class or object by attaching various adaptor classes
2. To attach to different implementation of an adapter that is derived from an abstract interface

BRIDGE

Purpose

The bridge design pattern breaks the direct and permanent link between the interface and the implementation formed by conventional language features which result in the plug and play capability of either the interface or the Implementation of the interface.

Utilization

1. The client referring an interface defined in an Active-X component is written in a language that does not support inheritance

2. Statically binding an interface to a class too restrictive.


OBJECT BY VALUE

Purpose

The object by value design passes or return an object by value from one function process to another resulting in the receiving process obtaining a copy of the object rather than a copy of an object reference.

Utilization

To pass or return a copy of an object to a caller
To pass or return a copy of an object from one process to another
To pass or return a copy of an object between dissimilar object systems


SMART PROXY

Purpose

The smart proxy design pattern provides a reference to a surrogate object that represents a real object in a given context

Utilization

1. If you want to provide transparent access with the more optimal performance to the real object, which does not reside in the same address space as the client thread that initiated the request

2. If you want to regulate access to the real object by requiring the client to have specific rights to invoke the properties and methods of the real object

3. If you want to defer creation of the real object until it’s needed


OBJECT FACTORY

Purpose

Define an interface for creating objects of a specific type. Object creation occurs in the concrete classes that implement this interface

Utilization

1. Keeps the client oblivious to the various classes of objects that support a particular interface expected by the client

2. Controls the object creation process, which is impossible using conventional language features such as the NEW key word or CREATE OBJECT function.


SINGLETON

Purpose

The purpose of the singleton design pattern is to permit the creation of only a single instance of a class and to provide a global point of access.

Utilization

Use of the singleton design pattern when the service of a specific object is required by other objects in the system and when the service must be globally accessible at the same time, the frequency with which clients use the service and the duration of processing the service must not be particularly long.

Scenario

You have designed an application that requires only a single connection to a database. Different components of the application run unique queries against tables in the database. The database object is globally accessible to all objects in the system. You could define a global database object, but there is no feature in the Microsoft Visual Basic language to prevent a client from creating another instance. Implementing a singleton design pattern will allow you to control the number of database objects that can be created.


REPOSITORY

Purpose

To define a common set of interface that allows an object’s state to be stored and retrieved from a data store.

Utilization

Use the repository design pattern for the following purpose

1. To save the state of an object at a specific moment in time.

2. To reestablish the state of an object from a specific moment in time

3. To abstract the varying implementations required to store and retrieve the state of an object from a specific data store

STATE

Purpose

Permit an object to change its behavior when its changes by virtue of changing its class at run time.

Utilization

Use the state design pattern for the following purpose

To alter an object’s behavior at run time based on changes to its internal state

To avoid compound conditional constructs based on an objects state, instead define distinct classes that represent the specific behavior at a given state.

EVENT SERVICE

Purpose

Decouple the direct communication between objects to minimize the interdependent relationship that constrain the ability to change or extend a system

Utilization

1. To extend a system’s functionality in a plug-and-play fashion.

2. To dynamically assemble relationship between objects.


MODEL VIEW CONTROLLER

Introduction

Design patterns are very useful to solve complex design problems if used properly. This article explains the basic concept of the Model View Controller (MVC) design pattern and also shows how closely .NET Framework can be used to implement the MVC design pattern with the one that originally conceived.

Definition/Description: Model View Controller (MVC)

View renders the data from the Model in response to the request made to the model by controlled events made by user interaction.

Model View Controller is a design approach to separate the application object model from GUI, originally invented around 80s. Then later on it has become a widely accepted common design pattern. The main objective behind this pattern is to decouple the view of the data (presentation layer) from the actual data processing so that the same model can be used for various views. This is achieved by using three different types of objects that interact with each other in loosely coupled manner with their discreet set of tasks.

These three objects are known as Model, View and Controller. We will learn for each of them here.





VIEW:

View is the graphical data presentation (outputting) irrespective of the real data processing. View is the responsible for look and feel, some custom formatting, sorting etc. View is completely isolated from actual complex data operations. For example, Online product catalog view is completely separated from database connection, query, tables etc. It simply gets final row-data from the model and puts some cosmetics and formatting before displaying it in browser. View provides interface to interact with the system. The beauty of MVC approach is that it supports any kind of view, which is challenging in todays distributed and multi-platform environment.
A MVC model can have multiple views, which are controlled by controller.
View interface can be of WEB-FORMS, HTML, XML/XSLT, XTML, and WML or can be Windows forms etc.

MODEL:

Model is responsible for actual data processing, like database connection, querying database, implementing business rules etc. It feeds data to the view without worrying about the actual formatting and look and feel. Data provided by Model is display-neutral so it can be interfaced with as many views without code redundancy; this eases your code maintenance and reduces bugs and allows code -reuse at good extent. Model responds to the request made by controllers and notifies the registered views to update their display with new data.

CONTROLLER:

Controller is responsible for Notice of action. Controller responds to the mouse or keyboard input to command model and view to change. Controllers are associated with views. User interaction triggers the events to change the model, which in turn calls some methods of model to update its state to notify other registered views to refresh their display.

Benefits:

Following are the few of the benefits of MVC design pattern.

Since MVC handles the multiple views using the same enterprise model it is easier to maintain, test and upgrade the multiple system.

It will be easier to add new clients just by adding their views and controllers.

Since the Model is completely decoupled from view it allows lot of flexibilities to design and implement the model considering reusability and modularity. This model also can be extended for further distributed application.

It is possible to have development process in parallel for model, view and controller.

This makes the application extensible and scalable.

Drawbacks:

Requires high skilled experienced professionals who can identify the requirements in depth at the front before actual design.

It requires the significant amount of time to analyze and design.

This design approach is not suitable for smaller applications. It Overkills the small applications.

Design Patterns

Design patterns are recurring solutions to software design problems you find again and again in real-world application development. Patterns are about design and interaction of objects, as well as providing a communication platform concerning elegant, reusable solutions to commonly encountered programming challenges.

The Gang of Four (GoF) patterns are generally considered the foundation for all other patterns. They are categorized in three groups: Creational, Structural, and Behavioral. Here you will find information on these important patterns.

To give you a head start, the C# source code is provided in 2 forms: 'structural' and 'real-world'.

Structural code uses type names as defined in the pattern definition and UML diagrams.

Real-world code provides real-world programming situations where you may use these patterns.

A third form, '.NET optimized' demonstrates design patterns that exploit built-in .NET features, such as, attributes, events, delegation, and reflection. These and much more are available in our unique Design Pattern FrameworkTM. For an example of a .NET optimized pattern see our Singleton page.

http://www.dofactory.com/Patterns/Patterns.aspx
http://www.developer.com/design/article.php/10925_1502691_2

I - Creational Patterns

1. Abstract Factory Creates an instance of several families of classes
2. Builder Separates object construction from its representation
3. Factory Method Creates an instance of several derived classes
4. Prototype A fully initialized instance to be copied or cloned
5. Singleton A class of which only a single instance can exist

II - Structural Patterns

1. Adapter Match interfaces of different classes
2. Bridge Separates an object’s interface from its implementation
3. Composite A tree structure of simple and composite objects
4. Decorator Add responsibilities to objects dynamically
5. Facade A single class that represents an entire subsystem
6. Flyweight A fine-grained instance used for efficient sharing
7. Proxy An object representing another object

III - Behavioral Patterns

1. Chain of Responsibility. A way of passing a request between a chain of objects
2. Command Encapsulate a command request as an object
3. Interpreter A way to include language elements in a program
4. Iterator Sequentially access the elements of a collection
5. Mediator Defines simplified communication between classes
6. Memento Capture and restore an object's internal state
7. Observer A way of notifying change to a number of classes
8. State Alter an object's behavior when its state changes
9. Strategy Encapsulates an algorithm inside a class
10. Template Method Defer the exact steps of an algorithm to a subclass
11. Visitor Defines a new operation to a class without change


1. Abstract Factory
The Abstract Factory is intended to provide a single interface for clients to use when they need to create a family of related objects without having to specify concrete classes. For example, imagine a system that needs to implement platform-specific user interface objects (menus, toolbars, and so forth) for several different platforms. Abstract Factory simplifies the interface for the client by localizing all of the initialization strategies within a single class, the Abstract Factory. The pattern works to ensure that all the strategies can work together correctly.
To understand Abstract Factory, examine the class diagram shown in the following figure. Note that there are two separate hierarchies. The first represents the various abstractions the client has interest in. For each abstraction, there exists an abstract class definition (AbstractClass1, AbstractClass2, and so on), and the subclasses that provide the concrete implementations (ConcreteClass1A, ConcreteClass1B, and so forth). In the second hierarchy, an abstract AbstractFactory class is defined to provide the interface for each class that is responsible for creating the members of a particular family. For example, ConcreteFactoryB is responsible for creating objects from classes ConcreteClass1B, ConcreteClass2B, and the like. All the client needs to worry about is which family of objects it is interested in creating and calling the appropriate Factory method. Because the client only knows about the abstract interface, it can interact with objects from different families without having to know about their internal implementation details. This approach has the benefit that the family can be allowed to grow without the need to modify the client. The primary drawback of AbstractFactory is that it can limit your flexibility when you want to take advantage of a specific capability a family may have. This is because you must provide a common interface across all families, even if some of them do not have this capability.

2. Builder
Builder is used to separate the construction of complex objects from their representation so the construction process can be used to create different representations. The construction logic is isolated from the actual steps used to create the complex object and, therefore, the construction process can be reused to create different complex objects from the same set of simple objects. This tends to reduce the size of classes by factoring out methods that are responsible for constructing complex objects into a single class (called a Director) that is responsible for knowing how to build complex objects. In addition, Builder can be used when you want to create objects in a step-wise manner depending on parameters you acquire along the way.
The class diagram shown in the next figure shows the client instantiates the Builder and Director classes. The Builder represents the complex object in terms of simpler objects and primitive types. The client then passes the Builder object, as a parameter, to the Director's constructor, which is responsible for calling the appropriate Builder methods. An abstract AbstractBuilder class is created to provide the Director with a uniform interface for all concrete Builder classes. Thus, you can add new types of complex objects by defining only the structure (Builder) and reuse the logic for the actual construction process (Director). Only the client needs to know about the new types. The Director simply needs to know which Builder methods to call.

3. Factory Method
When developing classes, you always provide constructors for your clients' use. There are certain circumstances in which you do not want your clients to know which class out of several to instantiate. The Factory Method is intended to define an interface for clients to use to create an object, but lets subclasses decide which class to instantiate. Factory Methods let a class defer instantiation to subclasses.
As the next class diagram shows, the pattern uses two types of classes. The Product classes, which are the classes that make up your application, and the Creator classes, which are responsible for defining the Factory methods used to create instances of Product objects on the clients behalf. The Creator class defines the factory method, which returns an object of type Product. The patterns uses abstract Product and Creator classes to provide the client with a uniform interface. Concrete classes provide the appropriate implementation for their respective base class. In addition, Creator may also define a default implementation of the factory method that returns a default ConcreteProduct object. It may also call the factory method to create a Product object. Any of these approaches can be used to balance the forces at work on your project.

4. Prototype
The Prototype is a simple pattern intended to provide you with a way to dynamically select which object to instantiate, and to return a clone of a prototypical object. This pattern is useful in applications that use a graphical toolbox to create instances of subclasses that represent the objects used by an application.
As the following class diagram shows, the pattern consists of an abstract Prototype class that defines a Clone(...) method that all concrete Prototypes implement. The client simply calls the Clone(...) method for the specific concrete Prototype it requires.


5. Singleton
There are a number of situations in programming where you need to assure that you have only one instance of a class. Print spoolers, window managers, and so forth, are examples of Singletons. The Singleton is intended to provide a way to ensure that a class provides one instance of itself, and to provide a global point of access.
The following class diagram shows the Singleton is a simple pattern. The Singleton class is responsible for instantiating itself and passing that instance on to the client. Therefore, the access modifier for the Singleton constructor must be either private or protected so the client cannot call the constructor itself. The Singleton also provides a method that returns the sole instance of itself to the client. The first time the client requests an instance, the Singleton will create that instance internally and store it as a private member. Each subsequent call from the client will return that instance.

1. Adapter
The Adapter is intended to provide a way for a client to use an object whose interface is different from the one expected by the client, without having to modify either. This pattern is suitable for solving issues that arise, for example, when: 1) you want to replace one class with another and the interfaces do not match, and 2) you want to create a class that can interact with other classes without knowing their interfaces at design time.
In the class diagram shown for Adapter in the following figure, the client wants to make a specific request of an object (Adaptee). Ordinarily, this would be accomplished by creating an instance of Adaptee and invoking SpecificRequest(...). In this case, however, the client cannot do so because the interfaces do not match (the parameter types are different). Adapter helps you address this incompatibility by providing classes that are responsible for redefining the data types on the client's behalf. First, you create a custom Target class that defines methods using an interface expected by the client. And second, you create a custom Adapter that implements the interface expected by the Adaptee. The Adapter class subclasses the Target, and provides an alternate implementation of the client requests in terms that the Adaptee expects. Adapter overrides the Target method and provides the correct interface for Adaptee. This approach has the advantage that it does not lead to modifications in the client. Adapter is a structural pattern and you can use it to react to changes in class interfaces as your system evolves, or you can proactively use the Adapter pattern to build systems that anticipate changing structural details.

2. Bridge
The Bridge is intended to decouple an abstraction from its implementation so both can vary independently. For example, a significant maintenance headache entails the coupling that occurs between custom classes and the class libraries they use. Bridges are useful for minimizing this coupling by providing an abstract description of the class libraries to the client. For example, a typical abstraction could be created for displaying a record set (DisplayRecordset as an Abstraction). The DisplayRecordset class could then be implemented using a variety of user interface elements (data grids, data lists, etc.), or with different formats (chart, table, and so forth). This has the effect of keeping the client interface constant while you are permitted to vary how abstractions are implemented. In addition, you can localize the logic used to determine which implementation and which abstraction the client object should use. The remaining client methods only need to know about the abstraction.
To illustrate the Bridge Pattern, consider the class diagram displayed in the following figure. The client would have a method such as "SetupAbstraction(...)" that would be responsible for determining which implementation to use for the abstraction. Then the client is free to interact with the Abstraction and the proper implementation class will respond.

3. Composite
The Composite is intended to allow you to compose tree structures to represent whole-part hierarchies so that clients can treat individual objects and compositions of objects uniformly. We often build tree structures where some nodes are containers of other nodes, and other nodes are "leaves." Instead of creating separate client code to manage each type of node, Composite lets a client work with either using the same code.
As the class following diagram shows, the composite pattern consists of an abstract class called a Component, which provides interface for nodes and leaves alike. In addition, the Component may also define a default implementation when it is appropriate. The Leaf and Composite classes provide their own implementations, as well. The key to this pattern is the Composite class, which uses a collection to create complex objects from other objects (Leaves or other Composites). In addition, the composite object provides a way to iterate the composition to execute operations on the individual objects in the composition.

4. Decorator
Ordinarily, an object inherits behavior from its subclasses. The decorator pattern is intended to give you a way to extend the behavior of an object, and you can also dynamically compose an object's behavior. Decorator allows you to do so without the need to create new subclasses.
When you examine the next class diagram, you will notice there are two basic types of classes. The Component, whose behavior you want to extend, and the Decorator, which implements the extended behavior. You can have any number of Components and Decorators. You also provide abstract classes for both types of classes so the client has a common interface. The key to the Decorator is the SetComponent(...) method, which takes a component as an argument. The client is responsible for instantiating the Component and passing it to the Decorator's constructor. The client is then free to utilize the Component's new methods, as implemented in the Director. A really nice feature of the Decorator pattern is that you can decorate specific instances of objects. This is difficult to do if you subclass your components directly.

5. Facade
With the many classes and subsystems we use, it is important to isolate our software and reduce coupling. The Facade Pattern is intended to provide a unified interface to a set of interfaces in a subsystem. The Facade defines a higher-level interface that makes the subsystems easier to use. There are several benefits to Facade. First, it provides developers with a common interface to the subsystem, leading to more uniform code. Second, it isolates your system and provides a layer of protection from complexities in your subsystems as they evolve. Third, this protection makes it easier to replace one subsystem with another because the dependencies are isolated. The main disadvantage of Facade is that it tends to limit your flexibility. You are free, however, to instantiate objects directly from the subsystems.
As the following class diagram shows, the facade pattern provides the client with a uniform interface to the subsystem. Often the code that is inside a facade would have to be inside client code without the facade. The subsystem code beneath the facade can change without affecting the client code.

6. Flyweight
The Flyweight pattern is useful for situations where you have a small number of different objects that might be needed a very large number of times—with slightly different data that can be externalized outside those objects. The Flyweight is intended to use sharing to support large numbers of fine-grained objects more efficiently and reduce resource usage. The pattern makes reference to an object's intrinsic data, that makes it unique and extrinsic data, that gets passed in as parameters. This pattern is useful for applications in which you may need to display icons to represent folders or some other object and don't want to add the overhead of creating new icons for each individual folder. An example would be the right pane of Microsoft Windows Explorer. In this type of situation, it may be better to share instances of a class. This pattern differs from a Singleton because you can have a small number of Flyweights, such as one for every different icon type.
In the next class diagram, the Flyweight class is abstract and defines an interface for all Flyweights to implement behavior to act on extrinsic data. The Concrete Flyweight implements the Flyweight interface and maintains the intrinsic data. A ConcreteFlyweight object must be sharable. Any data it stores must be intrinsic; that is, it must be independent of the ConcreteFlyweight object's context. Not all Flyweight subclasses need to be shared, so you can also create classes for unshared flyweight data, as well. The client is responsible for maintaining references to the flyweight objects and the extrinsic data (data that makes the instance unique).

7. Proxy
The Proxy is intended to provide you with a way to use a surrogate or placeholder to another object in order to control access to it. This pattern is useful for situations where object creation is a time consuming process and can make an application appear sluggish. A proxy object can provide the client with feedback while the object is being created. Proxy can also be used to provide a more sophisticated reference to an object. For example, the proxy object can implement additional logic on the objects behalf (security, remote procedure calls, an so forth).
The next class diagram shows the pattern consists of two types of classes. The Subject is the actual object the client is interested in. An abstract Subject class is defined to provide both the Proxy and the client with a uniform interface to the Actual Subject classes. The Request(...) method is responsible for creating and returning an instance of the Subject. The Proxy overrides this method with its own implementation and manages the reference to the ActualObject class. The Proxy can also implement its own functionality when instantiating the ActualObject class. The client is responsible for selecting and instantiating the Proxy, and some time later, making a call to the Request(...) method. The Proxy responds by returning the actual object.


1. Chain of Responsibility
One of the tenets of software engineering is to keep objects loosely coupled. The Chain of Responsibility is intended to promote loose coupling between the sender of a request and its receiver by giving more than one object an opportunity to handle the request. The receiving objects are chained and pass the request along the chain until one of the objects handles it.
The class diagram, as illustrated in the following figure, shows that the client instantiates the Request and passes it as a parameter to an instance of the Handler. Each concrete handler is responsible for implementing an action to take on the Request object, and to maintain a reference to the next handler in the chain. An abstract Handler is defined to provide a uniform interface for the concrete handlers. The client is responsible for creating Request objects and then passing them to the first handler in the chain. The chain (Handler1 -> Handler2 -> Handler3, and so forth) can be set by the client by calling the SetSuccessor(...) for each handler it instantiates.

2. Command
The Command pattern is intended to encapsulate a request as an object. For example, consider a window application that needs to make requests of objects responsible for the user interface. The client responds to input from the user by creating a command object and the receiver. It then passes this object to an Invoker object, which then takes the appropriate action. This allows the client to make requests without having to know anything about what action will take place. In addition, you can change that action without affecting the client. Practical uses for Command are for creating queues and stacks for supporting "undo" operations, configuration changes, and so on.
As shown in the following class diagram, the client instantiates the Receiver class and passes it as an argument to the constructor of the ConcreteCommand class. The Receiver is responsible for carrying out the specific actions required and fulfilling the request. An abstract class is defined to provide a uniform interface for the concrete Command class. The concrete Command classes are responsible for executing the appropriate methods on the Receiver. The client uses the Invoker to ask the Command when to carry out the request. One drawback to the Command pattern is that it tends to lead to a proliferation of small classes; however, it does lead to simpler clients for supporting modern user interfaces.



3. Interpreter
Some applications provide support for built-in scripting and macro languages so users can describe operations they can perform in the application. The Interpreter is intended to provide you with a way to define a representation of the grammar of a language with an interpreter that uses the representation to interpret sentences in the language.
The following class diagram shows that you define two types of classes. A Context is responsible for the data that is accessible to the Interpreter. You also define an abstract Expression class that declares an abstract Interpret operation. Terminal and Nonterminal concrete classes are defined that inherit the abstract Expression interface. They provide the implementation for the Interpet(...) function, which is responsible for the interpret operation to be performed on the terminal and nonterminal tokens, respectively, for the abstract tree syntax. In the case of nonterminal expressions, you need to define a class for each rule in your grammar. The client is responsible for creating the abstract syntax tree using the terminal and nonterminal expression objects as appropriate, and calling the interpret(...) method. Because the different expressions conform to the expression interface, the client can interpret the complete expression without knowing the structure of the abstract tree.

4. Iterator
The Iterator pattern provides a client with a way to access the elements of an aggregate object sequentially without having to know the underlying representation. Iterator also provides you with a way to define special Iterator classes that perform unique processing and return only specific elements of the data collection. The Iterator is especially useful because it provides the client with a common interface so it doesn't need to know anything about the underling data structure.
The following class diagram shows the Iterator pattern consists of a Node Collection, a Node class, and the Iterator classes. An abstract Iterator class provides a uniform interface for the various concrete Iterator classes to implement. The client creates instances of the Node collection and adds Nodes objects as appropriate. Finally, it creates an instance of the appropriate Iterator and uses it to traverses the node collection accordingly. With this technique, you can build a family of generic methods for traversing node collections.

5. Mediator
Applications with many classes tend to become brittle as communication between them becomes more complex. The more classes know about each other, the more difficult it becomes to change the software. Mediator is intended to define an object that encapsulates how a set of objects interacts. Mediator promotes loose coupling by keeping objects from referring to each other explicitly, and lets you vary their interaction independently.
The next class diagram shows that Mediator consists of two types of classes, Colleague and Mediator. Colleagues are the objects from your application that you want to interact, and Mediators are responsible for defining the interactions. In the Mediator class, you define the methods that act on the Colleague objects and a method for introducing Colleagues. The client is responsible for instantiating the appropriate Colleague objects and the Mediator, and passing the Colleague objects to the Mediator's IntroduceColleagues(...) method. The client can then invoke the appropriate method on the Colleague objects. The Mediator assures the requests are passed to the interacting Colleagues. The main benefit of Mediator is that the interactions between relating objects are removed from the objects themselves and localized in the Mediator.

6. Memento
Client code often needs to record the current state of an object, without being interested in the actual data values (for example,, supporting undo operations). To support this behavior, we can have the object record its internal data in a helper class called a Memento, and the client code can treat this object like a black box for storing its current state. Then, at some later point in time, the client can pass the Memento back into the object, to restore it to a previous state. The Memento provides you with a way to capture and externalize an object's internal state so that it can be restored at a later time. It does this by violating encapsulation and without making the object responsible for this capability itself.
The class diagram for memento (see the next figure) shows the Originator as the object whose state you want to persist. You need to define the Memento class, which is responsible for storing the internal state or the Originator object. Finally, you define a Caretaker class that is responsible for protecting the Memento object. The key to Memento is that the Originator defines methods for creating and setting the Memento. In addition, Memento objects implement dual interfaces: one for the Originator and one for the Caretaker. Caretaker sees a narrow interface to the Memento—it can only pass the Memento to other objects. Originator, in contrast, sees a wide interface, one that lets it access all the data necessary to restore itself to its previous state. Ideally, only the originator that produced the memento would be permitted to access the memento's internal state. The client decides when it wants to store the state of the originator. It does so by invoking the Originators CreateMemento(...) method. The state can be restored by invoking SetMemento(...).

7. Observer
The Observer pattern is useful when you need to present data in several different forms at once. The Observer is intended to provide you with a means to define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically. The object containing the data is separated from the objects that display the data and the display objects observe changes in that data.
As the next class diagram shows, there are basically two different types of objects: a Subject and an Observer. The Subject corresponds to the data object whose state you want to track. The Observer is the object that is interested in changes in the Subject object data. To set up the pattern, Subject classes implement a method for registering Observers and for attaching and detaching them from a collection object. In addition, Subjects also implement GetState(...) and SetState(...) methods for the Observer to call. Finally, you also need a notify(...) method to notify all registered Observers when the data has changed. In addition to the Subject, you can also create Subject subclasses to store the Subject's state to satisfy any special requirements of concrete Observers. For Observers, you define a custom abstract Observer class to provide clients with a uniform interface, and subclass the implementation details.

8. State
The State pattern is useful when you want to have an object represent the state of an application, and you want to change the state by changing that object. The State pattern is intended to provide a mechanism to allow an object to alter its behavior in response to internal state changes. To the client, it appears as though the object has changed its class. The benefit of the State pattern is that state-specific logic is localized in classes that represent that state.
The next class diagram shows how to implement the State pattern. You define a Context class and an abstract class, State class, which your custom State handlers can implement. The Context class is responsible for calling the appropriate state handlers. The client instantiates the Context class and calls the Request(...) method with the appropriate arguments. The Request(...) method then determines which state handler should handle the request and passes the data to the Handle(...) method. The benefit of the State pattern is deeply nested or complex if statements are localized in the Context class instead of the client. Therefore, when the state of an application has to change in response to use input, the client merely passes this data to the Context object and the appropriate updates to the application state are made.

9. Strategy
The Strategy pattern is very useful for situations where you would like to dynamically swap the algorithms used in an application. If you think of an algorithm as a strategy for accomplishing some task, you can begin to imagine ways to use Strategy. Strategy is intended to provide you with a means to define a family of algorithms, encapsulate each one as an object, and make them interchangeable. Strategy lets the algorithms vary independently from clients that use them.
The following class diagram shows the Strategy pattern basically consists of a context class and a set of strategy classes. You define an abstract strategy class that your custom strategy classes can implement. Each strategy object implements the algorithm that makes it unique. The client instantiates the strategy class and passes it as an argument when it calls the constructor of the context class. The client is then able to call methods on the context object and any strategy specific methods as necessary. Because the context creates an instance of the abstract Strategy, the client is effectively using polymorphism to call strategy-specific methods on the context object.


10. Template Method
The Template Method is a simple pattern. You have an abstract class that is the base class of a hierarchy, and the behavior that is common to all objects in the hierarchy is implemented in the abstract class. Other details are left to the individual subclasses. The Template pattern is basically a formalism of the idea of defining an algorithm in a class but leaving some of the details to be implemented in subclasses. Another way to think of the Template Method is that it allows you to define a skeleton of an algorithm in an operation and defer some of the steps to subclasses. Template Method lets subclasses redefine certain steps of an algorithm without changing the algorithm's structure.
The next class diagram shows the Template method simply consists of an abstract class and subclasses. These classes define a set of primitive behaviors that make up a specific piece of functionality in the application. Behaviors common to all objects (TemplateMethod(..)) are implemented in the abstract class. Subclasses are free to provide an alternate implementation (overriding a method), or to provide methods specific to a particular concrete class (such as Step1(...) and Step2(...)).

11. Visitor
The Visitor pattern uses an external class to act on data in other classes. This is a useful approach to you when you have a polymorphic operation that cannot reside in the class hierarchy. Visitor is also a useful way to extend the behavior of a class hierarchy without the need to alter existing classes or to implement the new behavior in every subclass that requires it.
The following class diagram shows that the Visitor pattern consists of two different types of classes, Elements and Visitors. Elements are the objects your application uses and Visitors are encapsulated behaviors that are required for each concrete Element. Each Element must implement the Accept( ) method, which takes Visitor as an argument. In addition, each Visitor must provide an implementation of the VisitElementX( ) method for each element in the object structure. The client acts to instantiate the element class and the visitor class. The client then passes the visitor object to the element's Accept( ) method, and then calls the elements methods to have it perform operations. The actual action that gets performed is determined by which visitor class was instantiated by the client.



ASP : Application Service Provider

An application service provider (ASP) is a company that offers individuals or enterprises access over the Internet to application programs and related services that would otherwise have to be located in their own personal or enterprise computers.