Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2012/ch2b 2w42 aa

2012-11-20T01:26:45Z

Aasawa: /* Additional Reading */

=Introduction =

==Facade Pattern==
Intent 
* Provide a unified interface to a set of interfaces in a subsystem. 
* Wrap a complicated subsystem with a simpler interface. 

Facade discusses encapsulating a complex subsystem within a single interface object. This reduces the learning curve necessary to successfully leverage the subsystem. It also promotes decoupling the subsystem from its potentially many clients. On the other hand, if the Facade is the only access point for the subsystem, it will limit the features and flexibility that “power users” may need. The Facade object should be a fairly simple advocate or facilitator. It should not become an all-knowing oracle or “god” object. 

== Adapter Pattern ==

Intent<ref>[http://sourcemaking.com/design_patterns/adapter Sourcemaking - Adapter Design Pattern - http://sourcemaking.com/design_patterns/adapter]</ref> 
* Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn’t otherwise because of incompatible interfaces. 
* Wrap an existing class with a new interface. 
* Impedance match an old component to a new system. 

Convert the interface of a class into another interface clients expect. Adapter lets classes worktogether that couldn't otherwise because of incompatible interfaces.

==Abstract Factory Pattern==

Intent 
* Provide an interface for creating families of related or dependent objects without specifying their concrete classes. 
* A hierarchy that encapsulates: many possible “platforms”, and the construction of a suite of “products”. 
* The new operator considered harmful. 

If an application is to be portable, it needs to encapsulate platform dependencies. These “platforms” might include: windowing system, operating system, database, etc. Too often, this encapsulatation is not engineered in advance, and lots of #ifdef case statements with options for all currently supported platforms begin to procreate like rabbits throughout the code. 

==Mediator Pattern==
Intent 

* Define an object that encapsulates how a set of objects interact. Mediator promotes loose coupling by keeping objects from referring to each other explicitly, and it lets you vary their interaction independently.
* Design an intermediary to decouple many peers.
* Promote the many-to-many relationships between interacting peers to “full object status”.

=Facade Pattern =

==Non-Software examples<ref>[http://aspalliance.com/970_Facade_Design_Pattern.2 ASPAlliance - Facade Design Pattern - http://aspalliance.com/970_Facade_Design_Pattern.2]</ref>==
In most of the Pizza centers, orders will be given through phone calls with the customer interacting with the Customer service representative. In this case, consumers do not have access to the Billing system, Kitchen and delivery department. The customer service representative acts as an interface and interacts with each of the departments involved in the transaction and ensures that Pizzas are delivered to the consumer. Customer Service representative corresponds to the facade. Individual departments involved in the transaction correspond to Sub-systems.

==Software examples==
Web Service Facade Solution Architecture provides an example for Facade design pattern. In this architectural solution, instead of rewriting legacy applications or customizing those with middleware to connect to other applications one by one, this solution helps create a "facade" for the legacy application. Other applications are easily "plugged into" this facade. By modeling a legacy application into its basic functions of create, read, update, and delete and then exposing these functions as Web methods, the Web service facade solution allows other applications to access legacy data by making use of common Web services through standardized protocols. In this way, Facade decouples layers so that they do not depend on each other which can make it easier to develop, to use and to promote code re-use.

== C# Example ==
using System;
using System.Collections.Generic; 
namespace DesignPatterns.Facade
{
public class OrderFacade
{
//Places an Order and Returns an Order ID
public int placeOrder(int CustomerID, List<BasketItem> Products)
{
Order anOrder = new Order();
OrderLine anOrderLine = new OrderLine();
Address DespatchAddress = Address.getCustomerDespatchAddress(CustomerID);
int OrderId = anOrder.requestOrderID();
anOrder.createOrder(OrderId, DespatchAddress);
anOrderLine.addOrderLinesToOrder(OrderId, Products);
return OrderId;
}
} 
//order class
public class Order
{
public int requestOrderID()
{
//Creates and Returns a Unique Order ID
} 
public void createOrder(int OrderId, Address DespatchAddress)
{
}
} 
//OrderLine Class
public class OrderLine
{
public void addOrderLinesToOrder(int OrderId, List<BasketItem> Products)
{
}
} 
//Public Customer
public class Address
{
public static Address getCustomerDespatchAddress(int CustomerID)
{
return new Address();
}
//Address properties
} 
public class BasketItem
{
//BasketItem Properties
}
}

=Adapter Pattern and Facade Pattern =

Adapter functions as a wrapper or modifier of an existing class. It provides a different or translated view of that class. 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. Reuse has always been painful and elusive. One reason has been the tribulation of designing something new, while reusing something old. There is always something not quite right between the old and the new. It may be physical dimensions or misalignment. It may be timing or synchronization. It may be unfortunate assumptions or competing standards. It is like the problem of inserting a new three-prong electrical plug in an old two-prong wall outlet – some kind of adapter or intermediary is necessary. 

Adapter is about creating an intermediary abstraction that translates, or maps, the old component to the new system. Clients call methods on the Adapter object which redirects them into calls to the legacy component. This strategy can be implemented either with inheritance or with aggregation. 

== Adapter Pattern Example ==
<pre>
interface Shape {
void draw(...);
}

Class LegacyLine {
void draw(..) { }
}

Class LegacyRectangle {
void draw(..) { }
}

Class Line implements Shape {
adapter = new LegacyLine();
void draw(...) {adapter.draw(...)}
}

Class Rectangle implements Shape {
adapter = new LegacyRectangle();
void draw(...) {adapter.draw(...)}
}
</pre>

In the example provided for the Facade pattern, the method placeOrder() uses the methods exposed by many other classes such as Order, OrderLine, Address etc to provide a high level view for the callers. The callers need not worry about the complexities in handling the sub-system. The users of the Class OrderFacade just invoke the method placeOrder() with the necessary arguments and rest of the process is taken care by placeOrder(). As can be seen in this case, a new method (placeOrder) was defined which has the logic and the necessary steps to handle all the sub-systems to create an order, create an id for the order, create a dispatch address etc.

In the example provided for the Adapter pattern, no new methods are defined. The existing method draw of LegacyRectangle is wrapped in a adapter class Rectangle. The methods in adapter classes does the necessary manipulations to the arguments and then passes to the original classes.

On similar lines, assume that the implementation and structure of BasketItem in Facade example needs to be changed. To handle such scenario, a new adapter class BasketItemAdapter is defined. It implements all the methods of the BasketItem and in each method makes necessary changes to the arguments and passes it to the new implementation as shown below.
== Example ==
<pre>
public Class BasketItemAdapter {
BasketItem newImplementation = new BasketItem();
void calculateCost(...) {
//make necessary modification
newImplementation.calculateCost(...);
}
}
</pre>

== Differences and similarities ==
* In both the Facade and Adapter pattern we have pre-existing classes.
* In the Facade, however, we do not have an interface we must design to, as we do in the Adapter pattern.
* We are not interested in polymorphic behavior<ref>[http://www.scribd.com/doc/2283673/Design-patterns-the-facade-and-adapter-pattern Scribd - Facade Design Pattern - http://www.scribd.com/doc/2283673/Design-patterns-the-facade-and-adapter-pattern]</ref> in the Facade, while in the Adapter, We probably am.(There are times when we just need to design to a particular API and therefore must use an Adapter)
* In the case of the Facade pattern, the motivation is to simplify the interface. With the Adapter, while simpler is better,We are trying to design to an existing interface and cannot simplify things even if a simpler interface were otherwise possible.

Bottom line is a Facade simplifies an interface while an Adapter converts the interface into a pre-existing interface.

=Abstract Factory Pattern and Facade Pattern =

Abstract factory pattern<ref>Freeman,E., and Robson,E.,and Bates,B.,and Sierra,K. 2004. Head First Design Patterns</ref> provides a level of indirection that abstracts the creation of families of related or dependent objects without directly specifying their concrete classes. The “factory” object has the responsibility for providing creation services for the entire platform family. Clients never create platform objects directly, they ask the factory to do that for them.

This mechanism makes exchanging product families easy because the specific class of the factory object appears only once in the application - where it is instantiated. The application can wholesale replace the entire family of products simply by instantiating a different concrete instance of the abstract factory. Because the service provided by the factory object is so pervasive, it is routinely implemented as a Singleton. 

== Abstract Factory Example ==
[[File:Abstract.JPG|600px|center]]

The AbstractFactory defines the interface that all of the concrete factories will need to implement in order to product Products. ConcreteFactoryA and ConcreteFactoryB have both implemented this interface here, creating two seperate families of product. Meanwhile, AbstractProductA and AbstractProductB are interfaces for the different types of product. Each factory will create one of each of these AbstractProducts.

The Client deals with AbstractFactory, AbstractProductA and AbstractProductB. It doesn't know anything about the implementations. The actual implementation of AbstractFactory that the Client uses is determined at runtime.

As you can see, one of the main benefits of this pattern is that the client is totally decoupled from the concrete products. Also, new product families can be easily added into the system, by just adding in a new type of ConcreteFactory that implements AbstractFactory, and creating the specific Product implementations.

== Facade Pattern Example ==

[[File:Facade-wo.JPG|300px|thumb|center|Without a Facade, the client has to deal with the intricacies of the sub system.]]

[[File:Facade-w.JPG|300px|thumb|center|With a Facade, the complexities of sub system are unified into a single interface making it readily usable for the client.]]

Considering the example for the Facade pattern, Client requires access to Employee objects, but in order to get that, it first need to contact the Database and retrieve the Company objects. It then retrieves Division objects from them and finally gains access to Employee objects. So, we see that It uses four classes and has to deal with complex details of the sub system. With Facade, the Client is shielded from most of the classes. It uses the Database Facade to retrieve Employee objects directly.

== Differences and similarities between Facade and Abstract Factory patterns ==
<ul>
<li>Facade is a structural design pattern whereas Abstract Factory pattern is a creational design pattern<ref>Erich,G., and Richard,H.,and Ralph,J.,and John,M.V. 1997. Design Patterns: Elements of Reusable Object-Oriented Software</ref>.
<li>Both are similar in a way that both provide an interface. Abstract Factory , provides kind of a Facade for creating products that belongs to its own factories.
<li>With the Abstract Factory Pattern we just provide a common factory builder for many different builders for the same thing. This can be used whenever we need to provide an interface to a set of builders meant to be used with something in common (the product) without bothering on what are we going to build or which factory are we going to use. The Facade pattern instead is used to provide a simple interface to a lot of different operations that the client classes should not see.
</ul>

Thus we see that both patterns achieve quite different goals. The facade pattern is used when you want to hide an implementation or it is about changing interface of some class or set of classes. On the other hand Abstarct factory pattern is used when you want to hide the details on constructing instances. Provide an interface for creating families of related or dependent objects without specifying their concrete classes.

=Mediator Pattern and Facade Pattern=
In Unix, permission to access system resources is managed at three levels of granularity: world, group, and owner. A group is a collection of users intended to model some functional affiliation. Each user on the system can be a member of one or more groups, and each group can have zero or more users assigned to it. Next figure shows three users that are assigned to all three groups. If we were to model this in software, we could decide to have User objects coupled to Group objects, and Group objects coupled to User objects. Then when changes occur, both classes and all their instances would be affected. An alternate approach would be to introduce “an additional level of indirection” - take the mapping of users to groups and groups to users, and make it an abstraction unto itself. This offers several advantages: Users and Groups are decoupled from one another, many mappings can easily be maintained and manipulated simultaneously, and the mapping abstraction can be extended in the future by defining derived classes. 

Partitioning a system into many objects generally enhances reusability, but proliferating interconnections between those objects tend to reduce it again. The mediator object: encapsulates all interconnections, acts as the hub of communication, is responsible for controlling and coordinating the interactions of its clients, and promotes loose coupling by keeping objects from referring to each other explicitly.

[[File:Mediator__1.gif]]

Colleagues (or peers) are not coupled to one another. Each talks to the Mediator, which in turn knows and conducts the orchestration of the others. The “many to many” mapping between colleagues that would otherwise exist, has been “promoted to full object status”. This new abstraction provides a locus of indirection where additional leverage can be hosted.

Mediator is similar to Facade in that it abstracts functionality of existing classes. Mediator abstracts/centralizes arbitrary communication between colleague objects, it routinely “adds value”, and it is known/referenced by the colleague objects (i.e. it defines a multidirectional protocol). In contrast, Facade defines a simpler interface to a subsystem, it doesn’t add new functionality, and it is not known by the subsystem classes (i.e. it defines a unidirectional protocol where it makes requests of the subsystem classes but not vice versa).

=References=
<references/>

== Additional Reading ==

* [http://java.dzone.com/articles/design-patterns-uncovered-1 Facade Pattern in Java] at java.dzone.com
* [http://www.dofactory.com/Patterns/PatternFacade.aspx Facade Pattern] at dofactory.com
* [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract Factory Pattern] at Wikipedia
* [http://en.wikipedia.org/wiki/Facade_pattern Facade Design Pattern] at Wikipedia
* [http://www.dofactory.com/topic/1675/facade-with-factory-pattern.aspx Facade with Factory pattern] at dofactory.com
* [http://stackoverflow.com/questions/11188869/what-is-the-differences-between-facade-pattern-and-abstarct-factory-pattern.html difference between facade and abstract factory pattern] at stackoverflow.com
* McDonald,J. 2008. Design Patterns

CSC/ECE 517 Fall 2012/ch2b 2w42 aa

2012-11-20T01:26:23Z

Aasawa: /* Additional Reading */

=Introduction =

==Facade Pattern==
Intent 
* Provide a unified interface to a set of interfaces in a subsystem. 
* Wrap a complicated subsystem with a simpler interface. 

Facade discusses encapsulating a complex subsystem within a single interface object. This reduces the learning curve necessary to successfully leverage the subsystem. It also promotes decoupling the subsystem from its potentially many clients. On the other hand, if the Facade is the only access point for the subsystem, it will limit the features and flexibility that “power users” may need. The Facade object should be a fairly simple advocate or facilitator. It should not become an all-knowing oracle or “god” object. 

== Adapter Pattern ==

Intent<ref>[http://sourcemaking.com/design_patterns/adapter Sourcemaking - Adapter Design Pattern - http://sourcemaking.com/design_patterns/adapter]</ref> 
* Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn’t otherwise because of incompatible interfaces. 
* Wrap an existing class with a new interface. 
* Impedance match an old component to a new system. 

Convert the interface of a class into another interface clients expect. Adapter lets classes worktogether that couldn't otherwise because of incompatible interfaces.

==Abstract Factory Pattern==

Intent 
* Provide an interface for creating families of related or dependent objects without specifying their concrete classes. 
* A hierarchy that encapsulates: many possible “platforms”, and the construction of a suite of “products”. 
* The new operator considered harmful. 

If an application is to be portable, it needs to encapsulate platform dependencies. These “platforms” might include: windowing system, operating system, database, etc. Too often, this encapsulatation is not engineered in advance, and lots of #ifdef case statements with options for all currently supported platforms begin to procreate like rabbits throughout the code. 

==Mediator Pattern==
Intent 

* Define an object that encapsulates how a set of objects interact. Mediator promotes loose coupling by keeping objects from referring to each other explicitly, and it lets you vary their interaction independently.
* Design an intermediary to decouple many peers.
* Promote the many-to-many relationships between interacting peers to “full object status”.

=Facade Pattern =

==Non-Software examples<ref>[http://aspalliance.com/970_Facade_Design_Pattern.2 ASPAlliance - Facade Design Pattern - http://aspalliance.com/970_Facade_Design_Pattern.2]</ref>==
In most of the Pizza centers, orders will be given through phone calls with the customer interacting with the Customer service representative. In this case, consumers do not have access to the Billing system, Kitchen and delivery department. The customer service representative acts as an interface and interacts with each of the departments involved in the transaction and ensures that Pizzas are delivered to the consumer. Customer Service representative corresponds to the facade. Individual departments involved in the transaction correspond to Sub-systems.

==Software examples==
Web Service Facade Solution Architecture provides an example for Facade design pattern. In this architectural solution, instead of rewriting legacy applications or customizing those with middleware to connect to other applications one by one, this solution helps create a "facade" for the legacy application. Other applications are easily "plugged into" this facade. By modeling a legacy application into its basic functions of create, read, update, and delete and then exposing these functions as Web methods, the Web service facade solution allows other applications to access legacy data by making use of common Web services through standardized protocols. In this way, Facade decouples layers so that they do not depend on each other which can make it easier to develop, to use and to promote code re-use.

== C# Example ==
using System;
using System.Collections.Generic; 
namespace DesignPatterns.Facade
{
public class OrderFacade
{
//Places an Order and Returns an Order ID
public int placeOrder(int CustomerID, List<BasketItem> Products)
{
Order anOrder = new Order();
OrderLine anOrderLine = new OrderLine();
Address DespatchAddress = Address.getCustomerDespatchAddress(CustomerID);
int OrderId = anOrder.requestOrderID();
anOrder.createOrder(OrderId, DespatchAddress);
anOrderLine.addOrderLinesToOrder(OrderId, Products);
return OrderId;
}
} 
//order class
public class Order
{
public int requestOrderID()
{
//Creates and Returns a Unique Order ID
} 
public void createOrder(int OrderId, Address DespatchAddress)
{
}
} 
//OrderLine Class
public class OrderLine
{
public void addOrderLinesToOrder(int OrderId, List<BasketItem> Products)
{
}
} 
//Public Customer
public class Address
{
public static Address getCustomerDespatchAddress(int CustomerID)
{
return new Address();
}
//Address properties
} 
public class BasketItem
{
//BasketItem Properties
}
}

=Adapter Pattern and Facade Pattern =

Adapter functions as a wrapper or modifier of an existing class. It provides a different or translated view of that class. 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. Reuse has always been painful and elusive. One reason has been the tribulation of designing something new, while reusing something old. There is always something not quite right between the old and the new. It may be physical dimensions or misalignment. It may be timing or synchronization. It may be unfortunate assumptions or competing standards. It is like the problem of inserting a new three-prong electrical plug in an old two-prong wall outlet – some kind of adapter or intermediary is necessary. 

Adapter is about creating an intermediary abstraction that translates, or maps, the old component to the new system. Clients call methods on the Adapter object which redirects them into calls to the legacy component. This strategy can be implemented either with inheritance or with aggregation. 

== Adapter Pattern Example ==
<pre>
interface Shape {
void draw(...);
}

Class LegacyLine {
void draw(..) { }
}

Class LegacyRectangle {
void draw(..) { }
}

Class Line implements Shape {
adapter = new LegacyLine();
void draw(...) {adapter.draw(...)}
}

Class Rectangle implements Shape {
adapter = new LegacyRectangle();
void draw(...) {adapter.draw(...)}
}
</pre>

In the example provided for the Facade pattern, the method placeOrder() uses the methods exposed by many other classes such as Order, OrderLine, Address etc to provide a high level view for the callers. The callers need not worry about the complexities in handling the sub-system. The users of the Class OrderFacade just invoke the method placeOrder() with the necessary arguments and rest of the process is taken care by placeOrder(). As can be seen in this case, a new method (placeOrder) was defined which has the logic and the necessary steps to handle all the sub-systems to create an order, create an id for the order, create a dispatch address etc.

In the example provided for the Adapter pattern, no new methods are defined. The existing method draw of LegacyRectangle is wrapped in a adapter class Rectangle. The methods in adapter classes does the necessary manipulations to the arguments and then passes to the original classes.

On similar lines, assume that the implementation and structure of BasketItem in Facade example needs to be changed. To handle such scenario, a new adapter class BasketItemAdapter is defined. It implements all the methods of the BasketItem and in each method makes necessary changes to the arguments and passes it to the new implementation as shown below.
== Example ==
<pre>
public Class BasketItemAdapter {
BasketItem newImplementation = new BasketItem();
void calculateCost(...) {
//make necessary modification
newImplementation.calculateCost(...);
}
}
</pre>

== Differences and similarities ==
* In both the Facade and Adapter pattern we have pre-existing classes.
* In the Facade, however, we do not have an interface we must design to, as we do in the Adapter pattern.
* We are not interested in polymorphic behavior<ref>[http://www.scribd.com/doc/2283673/Design-patterns-the-facade-and-adapter-pattern Scribd - Facade Design Pattern - http://www.scribd.com/doc/2283673/Design-patterns-the-facade-and-adapter-pattern]</ref> in the Facade, while in the Adapter, We probably am.(There are times when we just need to design to a particular API and therefore must use an Adapter)
* In the case of the Facade pattern, the motivation is to simplify the interface. With the Adapter, while simpler is better,We are trying to design to an existing interface and cannot simplify things even if a simpler interface were otherwise possible.

Bottom line is a Facade simplifies an interface while an Adapter converts the interface into a pre-existing interface.

=Abstract Factory Pattern and Facade Pattern =

Abstract factory pattern<ref>Freeman,E., and Robson,E.,and Bates,B.,and Sierra,K. 2004. Head First Design Patterns</ref> provides a level of indirection that abstracts the creation of families of related or dependent objects without directly specifying their concrete classes. The “factory” object has the responsibility for providing creation services for the entire platform family. Clients never create platform objects directly, they ask the factory to do that for them.

This mechanism makes exchanging product families easy because the specific class of the factory object appears only once in the application - where it is instantiated. The application can wholesale replace the entire family of products simply by instantiating a different concrete instance of the abstract factory. Because the service provided by the factory object is so pervasive, it is routinely implemented as a Singleton. 

== Abstract Factory Example ==
[[File:Abstract.JPG|600px|center]]

The AbstractFactory defines the interface that all of the concrete factories will need to implement in order to product Products. ConcreteFactoryA and ConcreteFactoryB have both implemented this interface here, creating two seperate families of product. Meanwhile, AbstractProductA and AbstractProductB are interfaces for the different types of product. Each factory will create one of each of these AbstractProducts.

The Client deals with AbstractFactory, AbstractProductA and AbstractProductB. It doesn't know anything about the implementations. The actual implementation of AbstractFactory that the Client uses is determined at runtime.

As you can see, one of the main benefits of this pattern is that the client is totally decoupled from the concrete products. Also, new product families can be easily added into the system, by just adding in a new type of ConcreteFactory that implements AbstractFactory, and creating the specific Product implementations.

== Facade Pattern Example ==

[[File:Facade-wo.JPG|300px|thumb|center|Without a Facade, the client has to deal with the intricacies of the sub system.]]

[[File:Facade-w.JPG|300px|thumb|center|With a Facade, the complexities of sub system are unified into a single interface making it readily usable for the client.]]

Considering the example for the Facade pattern, Client requires access to Employee objects, but in order to get that, it first need to contact the Database and retrieve the Company objects. It then retrieves Division objects from them and finally gains access to Employee objects. So, we see that It uses four classes and has to deal with complex details of the sub system. With Facade, the Client is shielded from most of the classes. It uses the Database Facade to retrieve Employee objects directly.

== Differences and similarities between Facade and Abstract Factory patterns ==
<ul>
<li>Facade is a structural design pattern whereas Abstract Factory pattern is a creational design pattern<ref>Erich,G., and Richard,H.,and Ralph,J.,and John,M.V. 1997. Design Patterns: Elements of Reusable Object-Oriented Software</ref>.
<li>Both are similar in a way that both provide an interface. Abstract Factory , provides kind of a Facade for creating products that belongs to its own factories.
<li>With the Abstract Factory Pattern we just provide a common factory builder for many different builders for the same thing. This can be used whenever we need to provide an interface to a set of builders meant to be used with something in common (the product) without bothering on what are we going to build or which factory are we going to use. The Facade pattern instead is used to provide a simple interface to a lot of different operations that the client classes should not see.
</ul>

Thus we see that both patterns achieve quite different goals. The facade pattern is used when you want to hide an implementation or it is about changing interface of some class or set of classes. On the other hand Abstarct factory pattern is used when you want to hide the details on constructing instances. Provide an interface for creating families of related or dependent objects without specifying their concrete classes.

=Mediator Pattern and Facade Pattern=
In Unix, permission to access system resources is managed at three levels of granularity: world, group, and owner. A group is a collection of users intended to model some functional affiliation. Each user on the system can be a member of one or more groups, and each group can have zero or more users assigned to it. Next figure shows three users that are assigned to all three groups. If we were to model this in software, we could decide to have User objects coupled to Group objects, and Group objects coupled to User objects. Then when changes occur, both classes and all their instances would be affected. An alternate approach would be to introduce “an additional level of indirection” - take the mapping of users to groups and groups to users, and make it an abstraction unto itself. This offers several advantages: Users and Groups are decoupled from one another, many mappings can easily be maintained and manipulated simultaneously, and the mapping abstraction can be extended in the future by defining derived classes. 

Partitioning a system into many objects generally enhances reusability, but proliferating interconnections between those objects tend to reduce it again. The mediator object: encapsulates all interconnections, acts as the hub of communication, is responsible for controlling and coordinating the interactions of its clients, and promotes loose coupling by keeping objects from referring to each other explicitly.

[[File:Mediator__1.gif]]

Colleagues (or peers) are not coupled to one another. Each talks to the Mediator, which in turn knows and conducts the orchestration of the others. The “many to many” mapping between colleagues that would otherwise exist, has been “promoted to full object status”. This new abstraction provides a locus of indirection where additional leverage can be hosted.

Mediator is similar to Facade in that it abstracts functionality of existing classes. Mediator abstracts/centralizes arbitrary communication between colleague objects, it routinely “adds value”, and it is known/referenced by the colleague objects (i.e. it defines a multidirectional protocol). In contrast, Facade defines a simpler interface to a subsystem, it doesn’t add new functionality, and it is not known by the subsystem classes (i.e. it defines a unidirectional protocol where it makes requests of the subsystem classes but not vice versa).

=References=
<references/>

== Additional Reading ==

* [http://java.dzone.com/articles/design-patterns-uncovered-1 Facade Pattern in Java] at java.dzone.com
* [http://www.dofactory.com/Patterns/PatternFacade.aspx Facade Pattern] at dofactory.com
* [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract Factory Pattern] at Wikipedia
* [http://en.wikipedia.org/wiki/Facaed_pattern Facade Design Pattern] at Wikipedia
* [http://www.dofactory.com/topic/1675/facade-with-factory-pattern.aspx Facade with Factory pattern] at dofactory.com
* [http://stackoverflow.com/questions/11188869/what-is-the-differences-between-facade-pattern-and-abstarct-factory-pattern.html difference between facade and abstract factory pattern] at stackoverflow.com
* McDonald,J. 2008. Design Patterns

CSC/ECE 517 Fall 2012/ch2b 2w42 aa

2012-11-20T01:23:56Z

Aasawa: /* Additional Reading */

=Introduction =

==Facade Pattern==
Intent 
* Provide a unified interface to a set of interfaces in a subsystem. 
* Wrap a complicated subsystem with a simpler interface. 

Facade discusses encapsulating a complex subsystem within a single interface object. This reduces the learning curve necessary to successfully leverage the subsystem. It also promotes decoupling the subsystem from its potentially many clients. On the other hand, if the Facade is the only access point for the subsystem, it will limit the features and flexibility that “power users” may need. The Facade object should be a fairly simple advocate or facilitator. It should not become an all-knowing oracle or “god” object. 

== Adapter Pattern ==

Intent<ref>[http://sourcemaking.com/design_patterns/adapter Sourcemaking - Adapter Design Pattern - http://sourcemaking.com/design_patterns/adapter]</ref> 
* Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn’t otherwise because of incompatible interfaces. 
* Wrap an existing class with a new interface. 
* Impedance match an old component to a new system. 

Convert the interface of a class into another interface clients expect. Adapter lets classes worktogether that couldn't otherwise because of incompatible interfaces.

==Abstract Factory Pattern==

Intent 
* Provide an interface for creating families of related or dependent objects without specifying their concrete classes. 
* A hierarchy that encapsulates: many possible “platforms”, and the construction of a suite of “products”. 
* The new operator considered harmful. 

If an application is to be portable, it needs to encapsulate platform dependencies. These “platforms” might include: windowing system, operating system, database, etc. Too often, this encapsulatation is not engineered in advance, and lots of #ifdef case statements with options for all currently supported platforms begin to procreate like rabbits throughout the code. 

==Mediator Pattern==
Intent 

* Define an object that encapsulates how a set of objects interact. Mediator promotes loose coupling by keeping objects from referring to each other explicitly, and it lets you vary their interaction independently.
* Design an intermediary to decouple many peers.
* Promote the many-to-many relationships between interacting peers to “full object status”.

=Facade Pattern =

==Non-Software examples<ref>[http://aspalliance.com/970_Facade_Design_Pattern.2 ASPAlliance - Facade Design Pattern - http://aspalliance.com/970_Facade_Design_Pattern.2]</ref>==
In most of the Pizza centers, orders will be given through phone calls with the customer interacting with the Customer service representative. In this case, consumers do not have access to the Billing system, Kitchen and delivery department. The customer service representative acts as an interface and interacts with each of the departments involved in the transaction and ensures that Pizzas are delivered to the consumer. Customer Service representative corresponds to the facade. Individual departments involved in the transaction correspond to Sub-systems.

==Software examples==
Web Service Facade Solution Architecture provides an example for Facade design pattern. In this architectural solution, instead of rewriting legacy applications or customizing those with middleware to connect to other applications one by one, this solution helps create a "facade" for the legacy application. Other applications are easily "plugged into" this facade. By modeling a legacy application into its basic functions of create, read, update, and delete and then exposing these functions as Web methods, the Web service facade solution allows other applications to access legacy data by making use of common Web services through standardized protocols. In this way, Facade decouples layers so that they do not depend on each other which can make it easier to develop, to use and to promote code re-use.

== C# Example ==
using System;
using System.Collections.Generic; 
namespace DesignPatterns.Facade
{
public class OrderFacade
{
//Places an Order and Returns an Order ID
public int placeOrder(int CustomerID, List<BasketItem> Products)
{
Order anOrder = new Order();
OrderLine anOrderLine = new OrderLine();
Address DespatchAddress = Address.getCustomerDespatchAddress(CustomerID);
int OrderId = anOrder.requestOrderID();
anOrder.createOrder(OrderId, DespatchAddress);
anOrderLine.addOrderLinesToOrder(OrderId, Products);
return OrderId;
}
} 
//order class
public class Order
{
public int requestOrderID()
{
//Creates and Returns a Unique Order ID
} 
public void createOrder(int OrderId, Address DespatchAddress)
{
}
} 
//OrderLine Class
public class OrderLine
{
public void addOrderLinesToOrder(int OrderId, List<BasketItem> Products)
{
}
} 
//Public Customer
public class Address
{
public static Address getCustomerDespatchAddress(int CustomerID)
{
return new Address();
}
//Address properties
} 
public class BasketItem
{
//BasketItem Properties
}
}

=Adapter Pattern and Facade Pattern =

Adapter functions as a wrapper or modifier of an existing class. It provides a different or translated view of that class. 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. Reuse has always been painful and elusive. One reason has been the tribulation of designing something new, while reusing something old. There is always something not quite right between the old and the new. It may be physical dimensions or misalignment. It may be timing or synchronization. It may be unfortunate assumptions or competing standards. It is like the problem of inserting a new three-prong electrical plug in an old two-prong wall outlet – some kind of adapter or intermediary is necessary. 

Adapter is about creating an intermediary abstraction that translates, or maps, the old component to the new system. Clients call methods on the Adapter object which redirects them into calls to the legacy component. This strategy can be implemented either with inheritance or with aggregation. 

== Adapter Pattern Example ==
<pre>
interface Shape {
void draw(...);
}

Class LegacyLine {
void draw(..) { }
}

Class LegacyRectangle {
void draw(..) { }
}

Class Line implements Shape {
adapter = new LegacyLine();
void draw(...) {adapter.draw(...)}
}

Class Rectangle implements Shape {
adapter = new LegacyRectangle();
void draw(...) {adapter.draw(...)}
}
</pre>

In the example provided for the Facade pattern, the method placeOrder() uses the methods exposed by many other classes such as Order, OrderLine, Address etc to provide a high level view for the callers. The callers need not worry about the complexities in handling the sub-system. The users of the Class OrderFacade just invoke the method placeOrder() with the necessary arguments and rest of the process is taken care by placeOrder(). As can be seen in this case, a new method (placeOrder) was defined which has the logic and the necessary steps to handle all the sub-systems to create an order, create an id for the order, create a dispatch address etc.

In the example provided for the Adapter pattern, no new methods are defined. The existing method draw of LegacyRectangle is wrapped in a adapter class Rectangle. The methods in adapter classes does the necessary manipulations to the arguments and then passes to the original classes.

On similar lines, assume that the implementation and structure of BasketItem in Facade example needs to be changed. To handle such scenario, a new adapter class BasketItemAdapter is defined. It implements all the methods of the BasketItem and in each method makes necessary changes to the arguments and passes it to the new implementation as shown below.
== Example ==
<pre>
public Class BasketItemAdapter {
BasketItem newImplementation = new BasketItem();
void calculateCost(...) {
//make necessary modification
newImplementation.calculateCost(...);
}
}
</pre>

== Differences and similarities ==
* In both the Facade and Adapter pattern we have pre-existing classes.
* In the Facade, however, we do not have an interface we must design to, as we do in the Adapter pattern.
* We are not interested in polymorphic behavior<ref>[http://www.scribd.com/doc/2283673/Design-patterns-the-facade-and-adapter-pattern Scribd - Facade Design Pattern - http://www.scribd.com/doc/2283673/Design-patterns-the-facade-and-adapter-pattern]</ref> in the Facade, while in the Adapter, We probably am.(There are times when we just need to design to a particular API and therefore must use an Adapter)
* In the case of the Facade pattern, the motivation is to simplify the interface. With the Adapter, while simpler is better,We are trying to design to an existing interface and cannot simplify things even if a simpler interface were otherwise possible.

Bottom line is a Facade simplifies an interface while an Adapter converts the interface into a pre-existing interface.

=Abstract Factory Pattern and Facade Pattern =

Abstract factory pattern<ref>Freeman,E., and Robson,E.,and Bates,B.,and Sierra,K. 2004. Head First Design Patterns</ref> provides a level of indirection that abstracts the creation of families of related or dependent objects without directly specifying their concrete classes. The “factory” object has the responsibility for providing creation services for the entire platform family. Clients never create platform objects directly, they ask the factory to do that for them.

This mechanism makes exchanging product families easy because the specific class of the factory object appears only once in the application - where it is instantiated. The application can wholesale replace the entire family of products simply by instantiating a different concrete instance of the abstract factory. Because the service provided by the factory object is so pervasive, it is routinely implemented as a Singleton. 

== Abstract Factory Example ==
[[File:Abstract.JPG|600px|center]]

The AbstractFactory defines the interface that all of the concrete factories will need to implement in order to product Products. ConcreteFactoryA and ConcreteFactoryB have both implemented this interface here, creating two seperate families of product. Meanwhile, AbstractProductA and AbstractProductB are interfaces for the different types of product. Each factory will create one of each of these AbstractProducts.

The Client deals with AbstractFactory, AbstractProductA and AbstractProductB. It doesn't know anything about the implementations. The actual implementation of AbstractFactory that the Client uses is determined at runtime.

As you can see, one of the main benefits of this pattern is that the client is totally decoupled from the concrete products. Also, new product families can be easily added into the system, by just adding in a new type of ConcreteFactory that implements AbstractFactory, and creating the specific Product implementations.

== Facade Pattern Example ==

[[File:Facade-wo.JPG|300px|thumb|center|Without a Facade, the client has to deal with the intricacies of the sub system.]]

[[File:Facade-w.JPG|300px|thumb|center|With a Facade, the complexities of sub system are unified into a single interface making it readily usable for the client.]]

Considering the example for the Facade pattern, Client requires access to Employee objects, but in order to get that, it first need to contact the Database and retrieve the Company objects. It then retrieves Division objects from them and finally gains access to Employee objects. So, we see that It uses four classes and has to deal with complex details of the sub system. With Facade, the Client is shielded from most of the classes. It uses the Database Facade to retrieve Employee objects directly.

== Differences and similarities between Facade and Abstract Factory patterns ==
<ul>
<li>Facade is a structural design pattern whereas Abstract Factory pattern is a creational design pattern<ref>Erich,G., and Richard,H.,and Ralph,J.,and John,M.V. 1997. Design Patterns: Elements of Reusable Object-Oriented Software</ref>.
<li>Both are similar in a way that both provide an interface. Abstract Factory , provides kind of a Facade for creating products that belongs to its own factories.
<li>With the Abstract Factory Pattern we just provide a common factory builder for many different builders for the same thing. This can be used whenever we need to provide an interface to a set of builders meant to be used with something in common (the product) without bothering on what are we going to build or which factory are we going to use. The Facade pattern instead is used to provide a simple interface to a lot of different operations that the client classes should not see.
</ul>

Thus we see that both patterns achieve quite different goals. The facade pattern is used when you want to hide an implementation or it is about changing interface of some class or set of classes. On the other hand Abstarct factory pattern is used when you want to hide the details on constructing instances. Provide an interface for creating families of related or dependent objects without specifying their concrete classes.

=Mediator Pattern and Facade Pattern=
In Unix, permission to access system resources is managed at three levels of granularity: world, group, and owner. A group is a collection of users intended to model some functional affiliation. Each user on the system can be a member of one or more groups, and each group can have zero or more users assigned to it. Next figure shows three users that are assigned to all three groups. If we were to model this in software, we could decide to have User objects coupled to Group objects, and Group objects coupled to User objects. Then when changes occur, both classes and all their instances would be affected. An alternate approach would be to introduce “an additional level of indirection” - take the mapping of users to groups and groups to users, and make it an abstraction unto itself. This offers several advantages: Users and Groups are decoupled from one another, many mappings can easily be maintained and manipulated simultaneously, and the mapping abstraction can be extended in the future by defining derived classes. 

Partitioning a system into many objects generally enhances reusability, but proliferating interconnections between those objects tend to reduce it again. The mediator object: encapsulates all interconnections, acts as the hub of communication, is responsible for controlling and coordinating the interactions of its clients, and promotes loose coupling by keeping objects from referring to each other explicitly.

[[File:Mediator__1.gif]]

Colleagues (or peers) are not coupled to one another. Each talks to the Mediator, which in turn knows and conducts the orchestration of the others. The “many to many” mapping between colleagues that would otherwise exist, has been “promoted to full object status”. This new abstraction provides a locus of indirection where additional leverage can be hosted.

Mediator is similar to Facade in that it abstracts functionality of existing classes. Mediator abstracts/centralizes arbitrary communication between colleague objects, it routinely “adds value”, and it is known/referenced by the colleague objects (i.e. it defines a multidirectional protocol). In contrast, Facade defines a simpler interface to a subsystem, it doesn’t add new functionality, and it is not known by the subsystem classes (i.e. it defines a unidirectional protocol where it makes requests of the subsystem classes but not vice versa).

=References=
<references/>

== Additional Reading ==

* [http://java.dzone.com/articles/design-patterns-uncovered-1 Facade Pattern in Java] at java.dzone.com
* [http://www.dofactory.com/Patterns/PatternFacade.aspx Facade Pattern] at dofactory.com
* [http://www.dofactory.com/topic/1675/facade-with-factory-pattern.aspx Facade with Factory pattern] at dofactory.com
* [http://stackoverflow.com/questions/11188869/what-is-the-differences-between-facade-pattern-and-abstarct-factory-pattern.html difference between facade and abstract factory pattern] at stackoverflow.com
* McDonald,J. 2008. Design Patterns

CSC/ECE 517 Fall 2012/ch2b 2w42 aa

2012-11-20T01:23:22Z

Aasawa: /* Differences and similarities between Facade and Abstract Factory patterns */

=Introduction =

==Facade Pattern==
Intent 
* Provide a unified interface to a set of interfaces in a subsystem. 
* Wrap a complicated subsystem with a simpler interface. 

Facade discusses encapsulating a complex subsystem within a single interface object. This reduces the learning curve necessary to successfully leverage the subsystem. It also promotes decoupling the subsystem from its potentially many clients. On the other hand, if the Facade is the only access point for the subsystem, it will limit the features and flexibility that “power users” may need. The Facade object should be a fairly simple advocate or facilitator. It should not become an all-knowing oracle or “god” object. 

== Adapter Pattern ==

Intent<ref>[http://sourcemaking.com/design_patterns/adapter Sourcemaking - Adapter Design Pattern - http://sourcemaking.com/design_patterns/adapter]</ref> 
* Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn’t otherwise because of incompatible interfaces. 
* Wrap an existing class with a new interface. 
* Impedance match an old component to a new system. 

Convert the interface of a class into another interface clients expect. Adapter lets classes worktogether that couldn't otherwise because of incompatible interfaces.

==Abstract Factory Pattern==

Intent 
* Provide an interface for creating families of related or dependent objects without specifying their concrete classes. 
* A hierarchy that encapsulates: many possible “platforms”, and the construction of a suite of “products”. 
* The new operator considered harmful. 

If an application is to be portable, it needs to encapsulate platform dependencies. These “platforms” might include: windowing system, operating system, database, etc. Too often, this encapsulatation is not engineered in advance, and lots of #ifdef case statements with options for all currently supported platforms begin to procreate like rabbits throughout the code. 

==Mediator Pattern==
Intent 

* Define an object that encapsulates how a set of objects interact. Mediator promotes loose coupling by keeping objects from referring to each other explicitly, and it lets you vary their interaction independently.
* Design an intermediary to decouple many peers.
* Promote the many-to-many relationships between interacting peers to “full object status”.

=Facade Pattern =

==Non-Software examples<ref>[http://aspalliance.com/970_Facade_Design_Pattern.2 ASPAlliance - Facade Design Pattern - http://aspalliance.com/970_Facade_Design_Pattern.2]</ref>==
In most of the Pizza centers, orders will be given through phone calls with the customer interacting with the Customer service representative. In this case, consumers do not have access to the Billing system, Kitchen and delivery department. The customer service representative acts as an interface and interacts with each of the departments involved in the transaction and ensures that Pizzas are delivered to the consumer. Customer Service representative corresponds to the facade. Individual departments involved in the transaction correspond to Sub-systems.

==Software examples==
Web Service Facade Solution Architecture provides an example for Facade design pattern. In this architectural solution, instead of rewriting legacy applications or customizing those with middleware to connect to other applications one by one, this solution helps create a "facade" for the legacy application. Other applications are easily "plugged into" this facade. By modeling a legacy application into its basic functions of create, read, update, and delete and then exposing these functions as Web methods, the Web service facade solution allows other applications to access legacy data by making use of common Web services through standardized protocols. In this way, Facade decouples layers so that they do not depend on each other which can make it easier to develop, to use and to promote code re-use.

== C# Example ==
using System;
using System.Collections.Generic; 
namespace DesignPatterns.Facade
{
public class OrderFacade
{
//Places an Order and Returns an Order ID
public int placeOrder(int CustomerID, List<BasketItem> Products)
{
Order anOrder = new Order();
OrderLine anOrderLine = new OrderLine();
Address DespatchAddress = Address.getCustomerDespatchAddress(CustomerID);
int OrderId = anOrder.requestOrderID();
anOrder.createOrder(OrderId, DespatchAddress);
anOrderLine.addOrderLinesToOrder(OrderId, Products);
return OrderId;
}
} 
//order class
public class Order
{
public int requestOrderID()
{
//Creates and Returns a Unique Order ID
} 
public void createOrder(int OrderId, Address DespatchAddress)
{
}
} 
//OrderLine Class
public class OrderLine
{
public void addOrderLinesToOrder(int OrderId, List<BasketItem> Products)
{
}
} 
//Public Customer
public class Address
{
public static Address getCustomerDespatchAddress(int CustomerID)
{
return new Address();
}
//Address properties
} 
public class BasketItem
{
//BasketItem Properties
}
}

=Adapter Pattern and Facade Pattern =

Adapter functions as a wrapper or modifier of an existing class. It provides a different or translated view of that class. 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. Reuse has always been painful and elusive. One reason has been the tribulation of designing something new, while reusing something old. There is always something not quite right between the old and the new. It may be physical dimensions or misalignment. It may be timing or synchronization. It may be unfortunate assumptions or competing standards. It is like the problem of inserting a new three-prong electrical plug in an old two-prong wall outlet – some kind of adapter or intermediary is necessary. 

Adapter is about creating an intermediary abstraction that translates, or maps, the old component to the new system. Clients call methods on the Adapter object which redirects them into calls to the legacy component. This strategy can be implemented either with inheritance or with aggregation. 

== Adapter Pattern Example ==
<pre>
interface Shape {
void draw(...);
}

Class LegacyLine {
void draw(..) { }
}

Class LegacyRectangle {
void draw(..) { }
}

Class Line implements Shape {
adapter = new LegacyLine();
void draw(...) {adapter.draw(...)}
}

Class Rectangle implements Shape {
adapter = new LegacyRectangle();
void draw(...) {adapter.draw(...)}
}
</pre>

In the example provided for the Facade pattern, the method placeOrder() uses the methods exposed by many other classes such as Order, OrderLine, Address etc to provide a high level view for the callers. The callers need not worry about the complexities in handling the sub-system. The users of the Class OrderFacade just invoke the method placeOrder() with the necessary arguments and rest of the process is taken care by placeOrder(). As can be seen in this case, a new method (placeOrder) was defined which has the logic and the necessary steps to handle all the sub-systems to create an order, create an id for the order, create a dispatch address etc.

In the example provided for the Adapter pattern, no new methods are defined. The existing method draw of LegacyRectangle is wrapped in a adapter class Rectangle. The methods in adapter classes does the necessary manipulations to the arguments and then passes to the original classes.

On similar lines, assume that the implementation and structure of BasketItem in Facade example needs to be changed. To handle such scenario, a new adapter class BasketItemAdapter is defined. It implements all the methods of the BasketItem and in each method makes necessary changes to the arguments and passes it to the new implementation as shown below.
== Example ==
<pre>
public Class BasketItemAdapter {
BasketItem newImplementation = new BasketItem();
void calculateCost(...) {
//make necessary modification
newImplementation.calculateCost(...);
}
}
</pre>

== Differences and similarities ==
* In both the Facade and Adapter pattern we have pre-existing classes.
* In the Facade, however, we do not have an interface we must design to, as we do in the Adapter pattern.
* We are not interested in polymorphic behavior<ref>[http://www.scribd.com/doc/2283673/Design-patterns-the-facade-and-adapter-pattern Scribd - Facade Design Pattern - http://www.scribd.com/doc/2283673/Design-patterns-the-facade-and-adapter-pattern]</ref> in the Facade, while in the Adapter, We probably am.(There are times when we just need to design to a particular API and therefore must use an Adapter)
* In the case of the Facade pattern, the motivation is to simplify the interface. With the Adapter, while simpler is better,We are trying to design to an existing interface and cannot simplify things even if a simpler interface were otherwise possible.

Bottom line is a Facade simplifies an interface while an Adapter converts the interface into a pre-existing interface.

=Abstract Factory Pattern and Facade Pattern =

Abstract factory pattern<ref>Freeman,E., and Robson,E.,and Bates,B.,and Sierra,K. 2004. Head First Design Patterns</ref> provides a level of indirection that abstracts the creation of families of related or dependent objects without directly specifying their concrete classes. The “factory” object has the responsibility for providing creation services for the entire platform family. Clients never create platform objects directly, they ask the factory to do that for them.

This mechanism makes exchanging product families easy because the specific class of the factory object appears only once in the application - where it is instantiated. The application can wholesale replace the entire family of products simply by instantiating a different concrete instance of the abstract factory. Because the service provided by the factory object is so pervasive, it is routinely implemented as a Singleton. 

== Abstract Factory Example ==
[[File:Abstract.JPG|600px|center]]

The AbstractFactory defines the interface that all of the concrete factories will need to implement in order to product Products. ConcreteFactoryA and ConcreteFactoryB have both implemented this interface here, creating two seperate families of product. Meanwhile, AbstractProductA and AbstractProductB are interfaces for the different types of product. Each factory will create one of each of these AbstractProducts.

The Client deals with AbstractFactory, AbstractProductA and AbstractProductB. It doesn't know anything about the implementations. The actual implementation of AbstractFactory that the Client uses is determined at runtime.

As you can see, one of the main benefits of this pattern is that the client is totally decoupled from the concrete products. Also, new product families can be easily added into the system, by just adding in a new type of ConcreteFactory that implements AbstractFactory, and creating the specific Product implementations.

== Facade Pattern Example ==

[[File:Facade-wo.JPG|300px|thumb|center|Without a Facade, the client has to deal with the intricacies of the sub system.]]

[[File:Facade-w.JPG|300px|thumb|center|With a Facade, the complexities of sub system are unified into a single interface making it readily usable for the client.]]

Considering the example for the Facade pattern, Client requires access to Employee objects, but in order to get that, it first need to contact the Database and retrieve the Company objects. It then retrieves Division objects from them and finally gains access to Employee objects. So, we see that It uses four classes and has to deal with complex details of the sub system. With Facade, the Client is shielded from most of the classes. It uses the Database Facade to retrieve Employee objects directly.

== Differences and similarities between Facade and Abstract Factory patterns ==
<ul>
<li>Facade is a structural design pattern whereas Abstract Factory pattern is a creational design pattern<ref>Erich,G., and Richard,H.,and Ralph,J.,and John,M.V. 1997. Design Patterns: Elements of Reusable Object-Oriented Software</ref>.
<li>Both are similar in a way that both provide an interface. Abstract Factory , provides kind of a Facade for creating products that belongs to its own factories.
<li>With the Abstract Factory Pattern we just provide a common factory builder for many different builders for the same thing. This can be used whenever we need to provide an interface to a set of builders meant to be used with something in common (the product) without bothering on what are we going to build or which factory are we going to use. The Facade pattern instead is used to provide a simple interface to a lot of different operations that the client classes should not see.
</ul>

Thus we see that both patterns achieve quite different goals. The facade pattern is used when you want to hide an implementation or it is about changing interface of some class or set of classes. On the other hand Abstarct factory pattern is used when you want to hide the details on constructing instances. Provide an interface for creating families of related or dependent objects without specifying their concrete classes.

=Mediator Pattern and Facade Pattern=
In Unix, permission to access system resources is managed at three levels of granularity: world, group, and owner. A group is a collection of users intended to model some functional affiliation. Each user on the system can be a member of one or more groups, and each group can have zero or more users assigned to it. Next figure shows three users that are assigned to all three groups. If we were to model this in software, we could decide to have User objects coupled to Group objects, and Group objects coupled to User objects. Then when changes occur, both classes and all their instances would be affected. An alternate approach would be to introduce “an additional level of indirection” - take the mapping of users to groups and groups to users, and make it an abstraction unto itself. This offers several advantages: Users and Groups are decoupled from one another, many mappings can easily be maintained and manipulated simultaneously, and the mapping abstraction can be extended in the future by defining derived classes. 

Partitioning a system into many objects generally enhances reusability, but proliferating interconnections between those objects tend to reduce it again. The mediator object: encapsulates all interconnections, acts as the hub of communication, is responsible for controlling and coordinating the interactions of its clients, and promotes loose coupling by keeping objects from referring to each other explicitly.

[[File:Mediator__1.gif]]

Colleagues (or peers) are not coupled to one another. Each talks to the Mediator, which in turn knows and conducts the orchestration of the others. The “many to many” mapping between colleagues that would otherwise exist, has been “promoted to full object status”. This new abstraction provides a locus of indirection where additional leverage can be hosted.

Mediator is similar to Facade in that it abstracts functionality of existing classes. Mediator abstracts/centralizes arbitrary communication between colleague objects, it routinely “adds value”, and it is known/referenced by the colleague objects (i.e. it defines a multidirectional protocol). In contrast, Facade defines a simpler interface to a subsystem, it doesn’t add new functionality, and it is not known by the subsystem classes (i.e. it defines a unidirectional protocol where it makes requests of the subsystem classes but not vice versa).

=References=
<references/>

== Additional Reading ==

* [http://java.dzone.com/articles/design-patterns-uncovered-1 Facade Pattern in Java] at java.dzone.com
* [http://www.dofactory.com/Patterns/PatternFacade.aspx Facade Pattern] at dofactory.com
* [http://www.dofactory.com/topic/1675/facade-with-factory-pattern.aspx Facade with Factory pattern] at dofactory.com
* [http://stackoverflow.com/questions/11188869/what-is-the-differences-between-facade-pattern-and-abstarct-factory-pattern.html difference between facade and abstract factory pattern] at stackoverflow.com
* [http://www.coderanch.com/t/99780/patterns/Factory-Abstract-Factory-Pattern Facade
* McDonald,J. 2008. Design Patterns

CSC/ECE 517 Fall 2012/ch2b 2w42 aa

2012-11-20T01:22:36Z

Aasawa: /* Abstract Factory Pattern and Facade Pattern */

=Introduction =

==Facade Pattern==
Intent 
* Provide a unified interface to a set of interfaces in a subsystem. 
* Wrap a complicated subsystem with a simpler interface. 

Facade discusses encapsulating a complex subsystem within a single interface object. This reduces the learning curve necessary to successfully leverage the subsystem. It also promotes decoupling the subsystem from its potentially many clients. On the other hand, if the Facade is the only access point for the subsystem, it will limit the features and flexibility that “power users” may need. The Facade object should be a fairly simple advocate or facilitator. It should not become an all-knowing oracle or “god” object. 

== Adapter Pattern ==

Intent<ref>[http://sourcemaking.com/design_patterns/adapter Sourcemaking - Adapter Design Pattern - http://sourcemaking.com/design_patterns/adapter]</ref> 
* Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn’t otherwise because of incompatible interfaces. 
* Wrap an existing class with a new interface. 
* Impedance match an old component to a new system. 

Convert the interface of a class into another interface clients expect. Adapter lets classes worktogether that couldn't otherwise because of incompatible interfaces.

==Abstract Factory Pattern==

Intent 
* Provide an interface for creating families of related or dependent objects without specifying their concrete classes. 
* A hierarchy that encapsulates: many possible “platforms”, and the construction of a suite of “products”. 
* The new operator considered harmful. 

If an application is to be portable, it needs to encapsulate platform dependencies. These “platforms” might include: windowing system, operating system, database, etc. Too often, this encapsulatation is not engineered in advance, and lots of #ifdef case statements with options for all currently supported platforms begin to procreate like rabbits throughout the code. 

==Mediator Pattern==
Intent 

* Define an object that encapsulates how a set of objects interact. Mediator promotes loose coupling by keeping objects from referring to each other explicitly, and it lets you vary their interaction independently.
* Design an intermediary to decouple many peers.
* Promote the many-to-many relationships between interacting peers to “full object status”.

=Facade Pattern =

==Non-Software examples<ref>[http://aspalliance.com/970_Facade_Design_Pattern.2 ASPAlliance - Facade Design Pattern - http://aspalliance.com/970_Facade_Design_Pattern.2]</ref>==
In most of the Pizza centers, orders will be given through phone calls with the customer interacting with the Customer service representative. In this case, consumers do not have access to the Billing system, Kitchen and delivery department. The customer service representative acts as an interface and interacts with each of the departments involved in the transaction and ensures that Pizzas are delivered to the consumer. Customer Service representative corresponds to the facade. Individual departments involved in the transaction correspond to Sub-systems.

==Software examples==
Web Service Facade Solution Architecture provides an example for Facade design pattern. In this architectural solution, instead of rewriting legacy applications or customizing those with middleware to connect to other applications one by one, this solution helps create a "facade" for the legacy application. Other applications are easily "plugged into" this facade. By modeling a legacy application into its basic functions of create, read, update, and delete and then exposing these functions as Web methods, the Web service facade solution allows other applications to access legacy data by making use of common Web services through standardized protocols. In this way, Facade decouples layers so that they do not depend on each other which can make it easier to develop, to use and to promote code re-use.

== C# Example ==
using System;
using System.Collections.Generic; 
namespace DesignPatterns.Facade
{
public class OrderFacade
{
//Places an Order and Returns an Order ID
public int placeOrder(int CustomerID, List<BasketItem> Products)
{
Order anOrder = new Order();
OrderLine anOrderLine = new OrderLine();
Address DespatchAddress = Address.getCustomerDespatchAddress(CustomerID);
int OrderId = anOrder.requestOrderID();
anOrder.createOrder(OrderId, DespatchAddress);
anOrderLine.addOrderLinesToOrder(OrderId, Products);
return OrderId;
}
} 
//order class
public class Order
{
public int requestOrderID()
{
//Creates and Returns a Unique Order ID
} 
public void createOrder(int OrderId, Address DespatchAddress)
{
}
} 
//OrderLine Class
public class OrderLine
{
public void addOrderLinesToOrder(int OrderId, List<BasketItem> Products)
{
}
} 
//Public Customer
public class Address
{
public static Address getCustomerDespatchAddress(int CustomerID)
{
return new Address();
}
//Address properties
} 
public class BasketItem
{
//BasketItem Properties
}
}

=Adapter Pattern and Facade Pattern =

Adapter functions as a wrapper or modifier of an existing class. It provides a different or translated view of that class. 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. Reuse has always been painful and elusive. One reason has been the tribulation of designing something new, while reusing something old. There is always something not quite right between the old and the new. It may be physical dimensions or misalignment. It may be timing or synchronization. It may be unfortunate assumptions or competing standards. It is like the problem of inserting a new three-prong electrical plug in an old two-prong wall outlet – some kind of adapter or intermediary is necessary. 

Adapter is about creating an intermediary abstraction that translates, or maps, the old component to the new system. Clients call methods on the Adapter object which redirects them into calls to the legacy component. This strategy can be implemented either with inheritance or with aggregation. 

== Adapter Pattern Example ==
<pre>
interface Shape {
void draw(...);
}

Class LegacyLine {
void draw(..) { }
}

Class LegacyRectangle {
void draw(..) { }
}

Class Line implements Shape {
adapter = new LegacyLine();
void draw(...) {adapter.draw(...)}
}

Class Rectangle implements Shape {
adapter = new LegacyRectangle();
void draw(...) {adapter.draw(...)}
}
</pre>

In the example provided for the Facade pattern, the method placeOrder() uses the methods exposed by many other classes such as Order, OrderLine, Address etc to provide a high level view for the callers. The callers need not worry about the complexities in handling the sub-system. The users of the Class OrderFacade just invoke the method placeOrder() with the necessary arguments and rest of the process is taken care by placeOrder(). As can be seen in this case, a new method (placeOrder) was defined which has the logic and the necessary steps to handle all the sub-systems to create an order, create an id for the order, create a dispatch address etc.

In the example provided for the Adapter pattern, no new methods are defined. The existing method draw of LegacyRectangle is wrapped in a adapter class Rectangle. The methods in adapter classes does the necessary manipulations to the arguments and then passes to the original classes.

On similar lines, assume that the implementation and structure of BasketItem in Facade example needs to be changed. To handle such scenario, a new adapter class BasketItemAdapter is defined. It implements all the methods of the BasketItem and in each method makes necessary changes to the arguments and passes it to the new implementation as shown below.
== Example ==
<pre>
public Class BasketItemAdapter {
BasketItem newImplementation = new BasketItem();
void calculateCost(...) {
//make necessary modification
newImplementation.calculateCost(...);
}
}
</pre>

== Differences and similarities ==
* In both the Facade and Adapter pattern we have pre-existing classes.
* In the Facade, however, we do not have an interface we must design to, as we do in the Adapter pattern.
* We are not interested in polymorphic behavior<ref>[http://www.scribd.com/doc/2283673/Design-patterns-the-facade-and-adapter-pattern Scribd - Facade Design Pattern - http://www.scribd.com/doc/2283673/Design-patterns-the-facade-and-adapter-pattern]</ref> in the Facade, while in the Adapter, We probably am.(There are times when we just need to design to a particular API and therefore must use an Adapter)
* In the case of the Facade pattern, the motivation is to simplify the interface. With the Adapter, while simpler is better,We are trying to design to an existing interface and cannot simplify things even if a simpler interface were otherwise possible.

Bottom line is a Facade simplifies an interface while an Adapter converts the interface into a pre-existing interface.

=Abstract Factory Pattern and Facade Pattern =

Abstract factory pattern<ref>Freeman,E., and Robson,E.,and Bates,B.,and Sierra,K. 2004. Head First Design Patterns</ref> provides a level of indirection that abstracts the creation of families of related or dependent objects without directly specifying their concrete classes. The “factory” object has the responsibility for providing creation services for the entire platform family. Clients never create platform objects directly, they ask the factory to do that for them.

This mechanism makes exchanging product families easy because the specific class of the factory object appears only once in the application - where it is instantiated. The application can wholesale replace the entire family of products simply by instantiating a different concrete instance of the abstract factory. Because the service provided by the factory object is so pervasive, it is routinely implemented as a Singleton. 

== Abstract Factory Example ==
[[File:Abstract.JPG|600px|center]]

The AbstractFactory defines the interface that all of the concrete factories will need to implement in order to product Products. ConcreteFactoryA and ConcreteFactoryB have both implemented this interface here, creating two seperate families of product. Meanwhile, AbstractProductA and AbstractProductB are interfaces for the different types of product. Each factory will create one of each of these AbstractProducts.

The Client deals with AbstractFactory, AbstractProductA and AbstractProductB. It doesn't know anything about the implementations. The actual implementation of AbstractFactory that the Client uses is determined at runtime.

As you can see, one of the main benefits of this pattern is that the client is totally decoupled from the concrete products. Also, new product families can be easily added into the system, by just adding in a new type of ConcreteFactory that implements AbstractFactory, and creating the specific Product implementations.

== Facade Pattern Example ==

[[File:Facade-wo.JPG|300px|thumb|center|Without a Facade, the client has to deal with the intricacies of the sub system.]]

[[File:Facade-w.JPG|300px|thumb|center|With a Facade, the complexities of sub system are unified into a single interface making it readily usable for the client.]]

Considering the example for the Facade pattern, Client requires access to Employee objects, but in order to get that, it first need to contact the Database and retrieve the Company objects. It then retrieves Division objects from them and finally gains access to Employee objects. So, we see that It uses four classes and has to deal with complex details of the sub system. With Facade, the Client is shielded from most of the classes. It uses the Database Facade to retrieve Employee objects directly.

== Differences and similarities between Facade and Abstract Factory patterns ==
<ul>
<li>Facade is a structural design pattern whereas Abstract Factory pattern is a creational design pattern.
<li>Both are similar in a way that both provide an interface. Abstract Factory , provides kind of a Facade for creating products that belongs to its own factories.
<li>With the Abstract Factory Pattern we just provide a common factory builder for many different builders for the same thing. This can be used whenever we need to provide an interface to a set of builders meant to be used with something in common (the product) without bothering on what are we going to build or which factory are we going to use. The Facade pattern instead is used to provide a simple interface to a lot of different operations that the client classes should not see.
</ul>

Thus we see that both patterns achieve quite different goals. The facade pattern is used when you want to hide an implementation or it is about changing interface of some class or set of classes. On the other hand Abstarct factory pattern is used when you want to hide the details on constructing instances. Provide an interface for creating families of related or dependent objects without specifying their concrete classes.

=Mediator Pattern and Facade Pattern=
In Unix, permission to access system resources is managed at three levels of granularity: world, group, and owner. A group is a collection of users intended to model some functional affiliation. Each user on the system can be a member of one or more groups, and each group can have zero or more users assigned to it. Next figure shows three users that are assigned to all three groups. If we were to model this in software, we could decide to have User objects coupled to Group objects, and Group objects coupled to User objects. Then when changes occur, both classes and all their instances would be affected. An alternate approach would be to introduce “an additional level of indirection” - take the mapping of users to groups and groups to users, and make it an abstraction unto itself. This offers several advantages: Users and Groups are decoupled from one another, many mappings can easily be maintained and manipulated simultaneously, and the mapping abstraction can be extended in the future by defining derived classes. 

Partitioning a system into many objects generally enhances reusability, but proliferating interconnections between those objects tend to reduce it again. The mediator object: encapsulates all interconnections, acts as the hub of communication, is responsible for controlling and coordinating the interactions of its clients, and promotes loose coupling by keeping objects from referring to each other explicitly.

[[File:Mediator__1.gif]]

Colleagues (or peers) are not coupled to one another. Each talks to the Mediator, which in turn knows and conducts the orchestration of the others. The “many to many” mapping between colleagues that would otherwise exist, has been “promoted to full object status”. This new abstraction provides a locus of indirection where additional leverage can be hosted.

Mediator is similar to Facade in that it abstracts functionality of existing classes. Mediator abstracts/centralizes arbitrary communication between colleague objects, it routinely “adds value”, and it is known/referenced by the colleague objects (i.e. it defines a multidirectional protocol). In contrast, Facade defines a simpler interface to a subsystem, it doesn’t add new functionality, and it is not known by the subsystem classes (i.e. it defines a unidirectional protocol where it makes requests of the subsystem classes but not vice versa).

=References=
<references/>

== Additional Reading ==

* [http://java.dzone.com/articles/design-patterns-uncovered-1 Facade Pattern in Java] at java.dzone.com
* [http://www.dofactory.com/Patterns/PatternFacade.aspx Facade Pattern] at dofactory.com
* [http://www.dofactory.com/topic/1675/facade-with-factory-pattern.aspx Facade with Factory pattern] at dofactory.com
* [http://stackoverflow.com/questions/11188869/what-is-the-differences-between-facade-pattern-and-abstarct-factory-pattern.html difference between facade and abstract factory pattern] at stackoverflow.com
* [http://www.coderanch.com/t/99780/patterns/Factory-Abstract-Factory-Pattern Facade
* McDonald,J. 2008. Design Patterns

CSC/ECE 517 Fall 2012/ch2b 2w42 aa

2012-11-20T01:21:12Z

Aasawa: /* Additional Reading */

=Introduction =

==Facade Pattern==
Intent 
* Provide a unified interface to a set of interfaces in a subsystem. 
* Wrap a complicated subsystem with a simpler interface. 

Facade discusses encapsulating a complex subsystem within a single interface object. This reduces the learning curve necessary to successfully leverage the subsystem. It also promotes decoupling the subsystem from its potentially many clients. On the other hand, if the Facade is the only access point for the subsystem, it will limit the features and flexibility that “power users” may need. The Facade object should be a fairly simple advocate or facilitator. It should not become an all-knowing oracle or “god” object. 

== Adapter Pattern ==

Intent<ref>[http://sourcemaking.com/design_patterns/adapter Sourcemaking - Adapter Design Pattern - http://sourcemaking.com/design_patterns/adapter]</ref> 
* Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn’t otherwise because of incompatible interfaces. 
* Wrap an existing class with a new interface. 
* Impedance match an old component to a new system. 

Convert the interface of a class into another interface clients expect. Adapter lets classes worktogether that couldn't otherwise because of incompatible interfaces.

==Abstract Factory Pattern==

Intent 
* Provide an interface for creating families of related or dependent objects without specifying their concrete classes. 
* A hierarchy that encapsulates: many possible “platforms”, and the construction of a suite of “products”. 
* The new operator considered harmful. 

If an application is to be portable, it needs to encapsulate platform dependencies. These “platforms” might include: windowing system, operating system, database, etc. Too often, this encapsulatation is not engineered in advance, and lots of #ifdef case statements with options for all currently supported platforms begin to procreate like rabbits throughout the code. 

==Mediator Pattern==
Intent 

* Define an object that encapsulates how a set of objects interact. Mediator promotes loose coupling by keeping objects from referring to each other explicitly, and it lets you vary their interaction independently.
* Design an intermediary to decouple many peers.
* Promote the many-to-many relationships between interacting peers to “full object status”.

=Facade Pattern =

==Non-Software examples<ref>[http://aspalliance.com/970_Facade_Design_Pattern.2 ASPAlliance - Facade Design Pattern - http://aspalliance.com/970_Facade_Design_Pattern.2]</ref>==
In most of the Pizza centers, orders will be given through phone calls with the customer interacting with the Customer service representative. In this case, consumers do not have access to the Billing system, Kitchen and delivery department. The customer service representative acts as an interface and interacts with each of the departments involved in the transaction and ensures that Pizzas are delivered to the consumer. Customer Service representative corresponds to the facade. Individual departments involved in the transaction correspond to Sub-systems.

==Software examples==
Web Service Facade Solution Architecture provides an example for Facade design pattern. In this architectural solution, instead of rewriting legacy applications or customizing those with middleware to connect to other applications one by one, this solution helps create a "facade" for the legacy application. Other applications are easily "plugged into" this facade. By modeling a legacy application into its basic functions of create, read, update, and delete and then exposing these functions as Web methods, the Web service facade solution allows other applications to access legacy data by making use of common Web services through standardized protocols. In this way, Facade decouples layers so that they do not depend on each other which can make it easier to develop, to use and to promote code re-use.

== C# Example ==
using System;
using System.Collections.Generic; 
namespace DesignPatterns.Facade
{
public class OrderFacade
{
//Places an Order and Returns an Order ID
public int placeOrder(int CustomerID, List<BasketItem> Products)
{
Order anOrder = new Order();
OrderLine anOrderLine = new OrderLine();
Address DespatchAddress = Address.getCustomerDespatchAddress(CustomerID);
int OrderId = anOrder.requestOrderID();
anOrder.createOrder(OrderId, DespatchAddress);
anOrderLine.addOrderLinesToOrder(OrderId, Products);
return OrderId;
}
} 
//order class
public class Order
{
public int requestOrderID()
{
//Creates and Returns a Unique Order ID
} 
public void createOrder(int OrderId, Address DespatchAddress)
{
}
} 
//OrderLine Class
public class OrderLine
{
public void addOrderLinesToOrder(int OrderId, List<BasketItem> Products)
{
}
} 
//Public Customer
public class Address
{
public static Address getCustomerDespatchAddress(int CustomerID)
{
return new Address();
}
//Address properties
} 
public class BasketItem
{
//BasketItem Properties
}
}

=Adapter Pattern and Facade Pattern =

Adapter functions as a wrapper or modifier of an existing class. It provides a different or translated view of that class. 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. Reuse has always been painful and elusive. One reason has been the tribulation of designing something new, while reusing something old. There is always something not quite right between the old and the new. It may be physical dimensions or misalignment. It may be timing or synchronization. It may be unfortunate assumptions or competing standards. It is like the problem of inserting a new three-prong electrical plug in an old two-prong wall outlet – some kind of adapter or intermediary is necessary. 

Adapter is about creating an intermediary abstraction that translates, or maps, the old component to the new system. Clients call methods on the Adapter object which redirects them into calls to the legacy component. This strategy can be implemented either with inheritance or with aggregation. 

== Adapter Pattern Example ==
<pre>
interface Shape {
void draw(...);
}

Class LegacyLine {
void draw(..) { }
}

Class LegacyRectangle {
void draw(..) { }
}

Class Line implements Shape {
adapter = new LegacyLine();
void draw(...) {adapter.draw(...)}
}

Class Rectangle implements Shape {
adapter = new LegacyRectangle();
void draw(...) {adapter.draw(...)}
}
</pre>

In the example provided for the Facade pattern, the method placeOrder() uses the methods exposed by many other classes such as Order, OrderLine, Address etc to provide a high level view for the callers. The callers need not worry about the complexities in handling the sub-system. The users of the Class OrderFacade just invoke the method placeOrder() with the necessary arguments and rest of the process is taken care by placeOrder(). As can be seen in this case, a new method (placeOrder) was defined which has the logic and the necessary steps to handle all the sub-systems to create an order, create an id for the order, create a dispatch address etc.

In the example provided for the Adapter pattern, no new methods are defined. The existing method draw of LegacyRectangle is wrapped in a adapter class Rectangle. The methods in adapter classes does the necessary manipulations to the arguments and then passes to the original classes.

On similar lines, assume that the implementation and structure of BasketItem in Facade example needs to be changed. To handle such scenario, a new adapter class BasketItemAdapter is defined. It implements all the methods of the BasketItem and in each method makes necessary changes to the arguments and passes it to the new implementation as shown below.
== Example ==
<pre>
public Class BasketItemAdapter {
BasketItem newImplementation = new BasketItem();
void calculateCost(...) {
//make necessary modification
newImplementation.calculateCost(...);
}
}
</pre>

== Differences and similarities ==
* In both the Facade and Adapter pattern we have pre-existing classes.
* In the Facade, however, we do not have an interface we must design to, as we do in the Adapter pattern.
* We are not interested in polymorphic behavior<ref>[http://www.scribd.com/doc/2283673/Design-patterns-the-facade-and-adapter-pattern Scribd - Facade Design Pattern - http://www.scribd.com/doc/2283673/Design-patterns-the-facade-and-adapter-pattern]</ref> in the Facade, while in the Adapter, We probably am.(There are times when we just need to design to a particular API and therefore must use an Adapter)
* In the case of the Facade pattern, the motivation is to simplify the interface. With the Adapter, while simpler is better,We are trying to design to an existing interface and cannot simplify things even if a simpler interface were otherwise possible.

Bottom line is a Facade simplifies an interface while an Adapter converts the interface into a pre-existing interface.

=Abstract Factory Pattern and Facade Pattern =

Abstract factory pattern provides a level of indirection that abstracts the creation of families of related or dependent objects without directly specifying their concrete classes. The “factory” object has the responsibility for providing creation services for the entire platform family. Clients never create platform objects directly, they ask the factory to do that for them.

This mechanism makes exchanging product families easy because the specific class of the factory object appears only once in the application - where it is instantiated. The application can wholesale replace the entire family of products simply by instantiating a different concrete instance of the abstract factory. Because the service provided by the factory object is so pervasive, it is routinely implemented as a Singleton. 

== Abstract Factory Example ==
[[File:Abstract.JPG|600px|center]]

The AbstractFactory defines the interface that all of the concrete factories will need to implement in order to product Products. ConcreteFactoryA and ConcreteFactoryB have both implemented this interface here, creating two seperate families of product. Meanwhile, AbstractProductA and AbstractProductB are interfaces for the different types of product. Each factory will create one of each of these AbstractProducts.

The Client deals with AbstractFactory, AbstractProductA and AbstractProductB. It doesn't know anything about the implementations. The actual implementation of AbstractFactory that the Client uses is determined at runtime.

As you can see, one of the main benefits of this pattern is that the client is totally decoupled from the concrete products. Also, new product families can be easily added into the system, by just adding in a new type of ConcreteFactory that implements AbstractFactory, and creating the specific Product implementations.

== Facade Pattern Example ==

[[File:Facade-wo.JPG|300px|thumb|center|Without a Facade, the client has to deal with the intricacies of the sub system.]]

[[File:Facade-w.JPG|300px|thumb|center|With a Facade, the complexities of sub system are unified into a single interface making it readily usable for the client.]]

Considering the example for the Facade pattern, Client requires access to Employee objects, but in order to get that, it first need to contact the Database and retrieve the Company objects. It then retrieves Division objects from them and finally gains access to Employee objects. So, we see that It uses four classes and has to deal with complex details of the sub system. With Facade, the Client is shielded from most of the classes. It uses the Database Facade to retrieve Employee objects directly.

== Differences and similarities between Facade and Abstract Factory patterns ==
<ul>
<li>Facade is a structural design pattern whereas Abstract Factory pattern is a creational design pattern.
<li>Both are similar in a way that both provide an interface. Abstract Factory , provides kind of a Facade for creating products that belongs to its own factories.
<li>With the Abstract Factory Pattern we just provide a common factory builder for many different builders for the same thing. This can be used whenever we need to provide an interface to a set of builders meant to be used with something in common (the product) without bothering on what are we going to build or which factory are we going to use. The Facade pattern instead is used to provide a simple interface to a lot of different operations that the client classes should not see.
</ul>

Thus we see that both patterns achieve quite different goals. The facade pattern is used when you want to hide an implementation or it is about changing interface of some class or set of classes. On the other hand Abstarct factory pattern is used when you want to hide the details on constructing instances. Provide an interface for creating families of related or dependent objects without specifying their concrete classes.

=Mediator Pattern and Facade Pattern=
In Unix, permission to access system resources is managed at three levels of granularity: world, group, and owner. A group is a collection of users intended to model some functional affiliation. Each user on the system can be a member of one or more groups, and each group can have zero or more users assigned to it. Next figure shows three users that are assigned to all three groups. If we were to model this in software, we could decide to have User objects coupled to Group objects, and Group objects coupled to User objects. Then when changes occur, both classes and all their instances would be affected. An alternate approach would be to introduce “an additional level of indirection” - take the mapping of users to groups and groups to users, and make it an abstraction unto itself. This offers several advantages: Users and Groups are decoupled from one another, many mappings can easily be maintained and manipulated simultaneously, and the mapping abstraction can be extended in the future by defining derived classes. 

Partitioning a system into many objects generally enhances reusability, but proliferating interconnections between those objects tend to reduce it again. The mediator object: encapsulates all interconnections, acts as the hub of communication, is responsible for controlling and coordinating the interactions of its clients, and promotes loose coupling by keeping objects from referring to each other explicitly.

[[File:Mediator__1.gif]]

Colleagues (or peers) are not coupled to one another. Each talks to the Mediator, which in turn knows and conducts the orchestration of the others. The “many to many” mapping between colleagues that would otherwise exist, has been “promoted to full object status”. This new abstraction provides a locus of indirection where additional leverage can be hosted.

Mediator is similar to Facade in that it abstracts functionality of existing classes. Mediator abstracts/centralizes arbitrary communication between colleague objects, it routinely “adds value”, and it is known/referenced by the colleague objects (i.e. it defines a multidirectional protocol). In contrast, Facade defines a simpler interface to a subsystem, it doesn’t add new functionality, and it is not known by the subsystem classes (i.e. it defines a unidirectional protocol where it makes requests of the subsystem classes but not vice versa).

=References=
<references/>

== Additional Reading ==

* [http://java.dzone.com/articles/design-patterns-uncovered-1 Facade Pattern in Java] at java.dzone.com
* [http://www.dofactory.com/Patterns/PatternFacade.aspx Facade Pattern] at dofactory.com
* [http://www.dofactory.com/topic/1675/facade-with-factory-pattern.aspx Facade with Factory pattern] at dofactory.com
* [http://stackoverflow.com/questions/11188869/what-is-the-differences-between-facade-pattern-and-abstarct-factory-pattern.html difference between facade and abstract factory pattern] at stackoverflow.com
* [http://www.coderanch.com/t/99780/patterns/Factory-Abstract-Factory-Pattern Facade
* McDonald,J. 2008. Design Patterns

CSC/ECE 517 Fall 2012/ch2b 2w42 aa

2012-11-20T01:19:43Z

Aasawa: /* Adapter Pattern */

=Introduction =

==Facade Pattern==
Intent 
* Provide a unified interface to a set of interfaces in a subsystem. 
* Wrap a complicated subsystem with a simpler interface. 

Facade discusses encapsulating a complex subsystem within a single interface object. This reduces the learning curve necessary to successfully leverage the subsystem. It also promotes decoupling the subsystem from its potentially many clients. On the other hand, if the Facade is the only access point for the subsystem, it will limit the features and flexibility that “power users” may need. The Facade object should be a fairly simple advocate or facilitator. It should not become an all-knowing oracle or “god” object. 

== Adapter Pattern ==

Intent<ref>[http://sourcemaking.com/design_patterns/adapter Sourcemaking - Adapter Design Pattern - http://sourcemaking.com/design_patterns/adapter]</ref> 
* Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn’t otherwise because of incompatible interfaces. 
* Wrap an existing class with a new interface. 
* Impedance match an old component to a new system. 

Convert the interface of a class into another interface clients expect. Adapter lets classes worktogether that couldn't otherwise because of incompatible interfaces.

==Abstract Factory Pattern==

Intent 
* Provide an interface for creating families of related or dependent objects without specifying their concrete classes. 
* A hierarchy that encapsulates: many possible “platforms”, and the construction of a suite of “products”. 
* The new operator considered harmful. 

If an application is to be portable, it needs to encapsulate platform dependencies. These “platforms” might include: windowing system, operating system, database, etc. Too often, this encapsulatation is not engineered in advance, and lots of #ifdef case statements with options for all currently supported platforms begin to procreate like rabbits throughout the code. 

==Mediator Pattern==
Intent 

* Define an object that encapsulates how a set of objects interact. Mediator promotes loose coupling by keeping objects from referring to each other explicitly, and it lets you vary their interaction independently.
* Design an intermediary to decouple many peers.
* Promote the many-to-many relationships between interacting peers to “full object status”.

=Facade Pattern =

==Non-Software examples<ref>[http://aspalliance.com/970_Facade_Design_Pattern.2 ASPAlliance - Facade Design Pattern - http://aspalliance.com/970_Facade_Design_Pattern.2]</ref>==
In most of the Pizza centers, orders will be given through phone calls with the customer interacting with the Customer service representative. In this case, consumers do not have access to the Billing system, Kitchen and delivery department. The customer service representative acts as an interface and interacts with each of the departments involved in the transaction and ensures that Pizzas are delivered to the consumer. Customer Service representative corresponds to the facade. Individual departments involved in the transaction correspond to Sub-systems.

==Software examples==
Web Service Facade Solution Architecture provides an example for Facade design pattern. In this architectural solution, instead of rewriting legacy applications or customizing those with middleware to connect to other applications one by one, this solution helps create a "facade" for the legacy application. Other applications are easily "plugged into" this facade. By modeling a legacy application into its basic functions of create, read, update, and delete and then exposing these functions as Web methods, the Web service facade solution allows other applications to access legacy data by making use of common Web services through standardized protocols. In this way, Facade decouples layers so that they do not depend on each other which can make it easier to develop, to use and to promote code re-use.

== C# Example ==
using System;
using System.Collections.Generic; 
namespace DesignPatterns.Facade
{
public class OrderFacade
{
//Places an Order and Returns an Order ID
public int placeOrder(int CustomerID, List<BasketItem> Products)
{
Order anOrder = new Order();
OrderLine anOrderLine = new OrderLine();
Address DespatchAddress = Address.getCustomerDespatchAddress(CustomerID);
int OrderId = anOrder.requestOrderID();
anOrder.createOrder(OrderId, DespatchAddress);
anOrderLine.addOrderLinesToOrder(OrderId, Products);
return OrderId;
}
} 
//order class
public class Order
{
public int requestOrderID()
{
//Creates and Returns a Unique Order ID
} 
public void createOrder(int OrderId, Address DespatchAddress)
{
}
} 
//OrderLine Class
public class OrderLine
{
public void addOrderLinesToOrder(int OrderId, List<BasketItem> Products)
{
}
} 
//Public Customer
public class Address
{
public static Address getCustomerDespatchAddress(int CustomerID)
{
return new Address();
}
//Address properties
} 
public class BasketItem
{
//BasketItem Properties
}
}

=Adapter Pattern and Facade Pattern =

Adapter functions as a wrapper or modifier of an existing class. It provides a different or translated view of that class. 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. Reuse has always been painful and elusive. One reason has been the tribulation of designing something new, while reusing something old. There is always something not quite right between the old and the new. It may be physical dimensions or misalignment. It may be timing or synchronization. It may be unfortunate assumptions or competing standards. It is like the problem of inserting a new three-prong electrical plug in an old two-prong wall outlet – some kind of adapter or intermediary is necessary. 

Adapter is about creating an intermediary abstraction that translates, or maps, the old component to the new system. Clients call methods on the Adapter object which redirects them into calls to the legacy component. This strategy can be implemented either with inheritance or with aggregation. 

== Adapter Pattern Example ==
<pre>
interface Shape {
void draw(...);
}

Class LegacyLine {
void draw(..) { }
}

Class LegacyRectangle {
void draw(..) { }
}

Class Line implements Shape {
adapter = new LegacyLine();
void draw(...) {adapter.draw(...)}
}

Class Rectangle implements Shape {
adapter = new LegacyRectangle();
void draw(...) {adapter.draw(...)}
}
</pre>

In the example provided for the Facade pattern, the method placeOrder() uses the methods exposed by many other classes such as Order, OrderLine, Address etc to provide a high level view for the callers. The callers need not worry about the complexities in handling the sub-system. The users of the Class OrderFacade just invoke the method placeOrder() with the necessary arguments and rest of the process is taken care by placeOrder(). As can be seen in this case, a new method (placeOrder) was defined which has the logic and the necessary steps to handle all the sub-systems to create an order, create an id for the order, create a dispatch address etc.

In the example provided for the Adapter pattern, no new methods are defined. The existing method draw of LegacyRectangle is wrapped in a adapter class Rectangle. The methods in adapter classes does the necessary manipulations to the arguments and then passes to the original classes.

On similar lines, assume that the implementation and structure of BasketItem in Facade example needs to be changed. To handle such scenario, a new adapter class BasketItemAdapter is defined. It implements all the methods of the BasketItem and in each method makes necessary changes to the arguments and passes it to the new implementation as shown below.
== Example ==
<pre>
public Class BasketItemAdapter {
BasketItem newImplementation = new BasketItem();
void calculateCost(...) {
//make necessary modification
newImplementation.calculateCost(...);
}
}
</pre>

== Differences and similarities ==
* In both the Facade and Adapter pattern we have pre-existing classes.
* In the Facade, however, we do not have an interface we must design to, as we do in the Adapter pattern.
* We are not interested in polymorphic behavior<ref>[http://www.scribd.com/doc/2283673/Design-patterns-the-facade-and-adapter-pattern Scribd - Facade Design Pattern - http://www.scribd.com/doc/2283673/Design-patterns-the-facade-and-adapter-pattern]</ref> in the Facade, while in the Adapter, We probably am.(There are times when we just need to design to a particular API and therefore must use an Adapter)
* In the case of the Facade pattern, the motivation is to simplify the interface. With the Adapter, while simpler is better,We are trying to design to an existing interface and cannot simplify things even if a simpler interface were otherwise possible.

Bottom line is a Facade simplifies an interface while an Adapter converts the interface into a pre-existing interface.

=Abstract Factory Pattern and Facade Pattern =

Abstract factory pattern provides a level of indirection that abstracts the creation of families of related or dependent objects without directly specifying their concrete classes. The “factory” object has the responsibility for providing creation services for the entire platform family. Clients never create platform objects directly, they ask the factory to do that for them.

This mechanism makes exchanging product families easy because the specific class of the factory object appears only once in the application - where it is instantiated. The application can wholesale replace the entire family of products simply by instantiating a different concrete instance of the abstract factory. Because the service provided by the factory object is so pervasive, it is routinely implemented as a Singleton. 

== Abstract Factory Example ==
[[File:Abstract.JPG|600px|center]]

The AbstractFactory defines the interface that all of the concrete factories will need to implement in order to product Products. ConcreteFactoryA and ConcreteFactoryB have both implemented this interface here, creating two seperate families of product. Meanwhile, AbstractProductA and AbstractProductB are interfaces for the different types of product. Each factory will create one of each of these AbstractProducts.

The Client deals with AbstractFactory, AbstractProductA and AbstractProductB. It doesn't know anything about the implementations. The actual implementation of AbstractFactory that the Client uses is determined at runtime.

As you can see, one of the main benefits of this pattern is that the client is totally decoupled from the concrete products. Also, new product families can be easily added into the system, by just adding in a new type of ConcreteFactory that implements AbstractFactory, and creating the specific Product implementations.

== Facade Pattern Example ==

[[File:Facade-wo.JPG|300px|thumb|center|Without a Facade, the client has to deal with the intricacies of the sub system.]]

[[File:Facade-w.JPG|300px|thumb|center|With a Facade, the complexities of sub system are unified into a single interface making it readily usable for the client.]]

Considering the example for the Facade pattern, Client requires access to Employee objects, but in order to get that, it first need to contact the Database and retrieve the Company objects. It then retrieves Division objects from them and finally gains access to Employee objects. So, we see that It uses four classes and has to deal with complex details of the sub system. With Facade, the Client is shielded from most of the classes. It uses the Database Facade to retrieve Employee objects directly.

== Differences and similarities between Facade and Abstract Factory patterns ==
<ul>
<li>Facade is a structural design pattern whereas Abstract Factory pattern is a creational design pattern.
<li>Both are similar in a way that both provide an interface. Abstract Factory , provides kind of a Facade for creating products that belongs to its own factories.
<li>With the Abstract Factory Pattern we just provide a common factory builder for many different builders for the same thing. This can be used whenever we need to provide an interface to a set of builders meant to be used with something in common (the product) without bothering on what are we going to build or which factory are we going to use. The Facade pattern instead is used to provide a simple interface to a lot of different operations that the client classes should not see.
</ul>

Thus we see that both patterns achieve quite different goals. The facade pattern is used when you want to hide an implementation or it is about changing interface of some class or set of classes. On the other hand Abstarct factory pattern is used when you want to hide the details on constructing instances. Provide an interface for creating families of related or dependent objects without specifying their concrete classes.

=Mediator Pattern and Facade Pattern=
In Unix, permission to access system resources is managed at three levels of granularity: world, group, and owner. A group is a collection of users intended to model some functional affiliation. Each user on the system can be a member of one or more groups, and each group can have zero or more users assigned to it. Next figure shows three users that are assigned to all three groups. If we were to model this in software, we could decide to have User objects coupled to Group objects, and Group objects coupled to User objects. Then when changes occur, both classes and all their instances would be affected. An alternate approach would be to introduce “an additional level of indirection” - take the mapping of users to groups and groups to users, and make it an abstraction unto itself. This offers several advantages: Users and Groups are decoupled from one another, many mappings can easily be maintained and manipulated simultaneously, and the mapping abstraction can be extended in the future by defining derived classes. 

Partitioning a system into many objects generally enhances reusability, but proliferating interconnections between those objects tend to reduce it again. The mediator object: encapsulates all interconnections, acts as the hub of communication, is responsible for controlling and coordinating the interactions of its clients, and promotes loose coupling by keeping objects from referring to each other explicitly.

[[File:Mediator__1.gif]]

Colleagues (or peers) are not coupled to one another. Each talks to the Mediator, which in turn knows and conducts the orchestration of the others. The “many to many” mapping between colleagues that would otherwise exist, has been “promoted to full object status”. This new abstraction provides a locus of indirection where additional leverage can be hosted.

Mediator is similar to Facade in that it abstracts functionality of existing classes. Mediator abstracts/centralizes arbitrary communication between colleague objects, it routinely “adds value”, and it is known/referenced by the colleague objects (i.e. it defines a multidirectional protocol). In contrast, Facade defines a simpler interface to a subsystem, it doesn’t add new functionality, and it is not known by the subsystem classes (i.e. it defines a unidirectional protocol where it makes requests of the subsystem classes but not vice versa).

=References=
<references/>

== Additional Reading ==

* [http://java.dzone.com/articles/design-patterns-uncovered-1 Facade Pattern in Java] at java.dzone.com
* [http://www.cs.mcgill.ca/~hv/classes/CS400/01.hchen/doc/command/command.html Basics of Command Pattern]
* [http://www.dofactory.com/Patterns/PatternFacade.aspx Facade Pattern] at dofactory.com
* [http://www.dofactory.com/topic/1675/facade-with-factory-pattern.aspx Facade with Factory pattern] at dofactory.com
* [http://stackoverflow.com/questions/11188869/what-is-the-differences-between-facade-pattern-and-abstarct-factory-pattern.html difference between facade and abstract factory pattern] at stackoverflow.com
* [http://sourcemaking.com/design_patterns/command Behavorial Design Pattern - Command Pattern] at sourcemaking.com
* [http://www.coderanch.com/t/99780/patterns/Factory-Abstract-Factory-Pattern Facade
* [http://perfectjpattern.sourceforge.net/dp-command.html GoF Command Pattern]

* McDonald,J. 2008. Design Patterns

CSC/ECE 517 Fall 2012/ch2b 2w42 aa

2012-11-20T01:18:31Z

Aasawa: /* Adapter Pattern */

=Introduction =

==Facade Pattern==
Intent 
* Provide a unified interface to a set of interfaces in a subsystem. 
* Wrap a complicated subsystem with a simpler interface. 

Facade discusses encapsulating a complex subsystem within a single interface object. This reduces the learning curve necessary to successfully leverage the subsystem. It also promotes decoupling the subsystem from its potentially many clients. On the other hand, if the Facade is the only access point for the subsystem, it will limit the features and flexibility that “power users” may need. The Facade object should be a fairly simple advocate or facilitator. It should not become an all-knowing oracle or “god” object. 

== Adapter Pattern ==

Intenthttp://sourcemaking.com/design_patterns/adapter 
* Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn’t otherwise because of incompatible interfaces. 
* Wrap an existing class with a new interface. 
* Impedance match an old component to a new system. 

Convert the interface of a class into another interface clients expect. Adapter lets classes worktogether that couldn't otherwise because of incompatible interfaces.

==Abstract Factory Pattern==

Intent 
* Provide an interface for creating families of related or dependent objects without specifying their concrete classes. 
* A hierarchy that encapsulates: many possible “platforms”, and the construction of a suite of “products”. 
* The new operator considered harmful. 

If an application is to be portable, it needs to encapsulate platform dependencies. These “platforms” might include: windowing system, operating system, database, etc. Too often, this encapsulatation is not engineered in advance, and lots of #ifdef case statements with options for all currently supported platforms begin to procreate like rabbits throughout the code. 

==Mediator Pattern==
Intent 

* Define an object that encapsulates how a set of objects interact. Mediator promotes loose coupling by keeping objects from referring to each other explicitly, and it lets you vary their interaction independently.
* Design an intermediary to decouple many peers.
* Promote the many-to-many relationships between interacting peers to “full object status”.

=Facade Pattern =

==Non-Software examples<ref>[http://aspalliance.com/970_Facade_Design_Pattern.2 ASPAlliance - Facade Design Pattern - http://aspalliance.com/970_Facade_Design_Pattern.2]</ref>==
In most of the Pizza centers, orders will be given through phone calls with the customer interacting with the Customer service representative. In this case, consumers do not have access to the Billing system, Kitchen and delivery department. The customer service representative acts as an interface and interacts with each of the departments involved in the transaction and ensures that Pizzas are delivered to the consumer. Customer Service representative corresponds to the facade. Individual departments involved in the transaction correspond to Sub-systems.

==Software examples==
Web Service Facade Solution Architecture provides an example for Facade design pattern. In this architectural solution, instead of rewriting legacy applications or customizing those with middleware to connect to other applications one by one, this solution helps create a "facade" for the legacy application. Other applications are easily "plugged into" this facade. By modeling a legacy application into its basic functions of create, read, update, and delete and then exposing these functions as Web methods, the Web service facade solution allows other applications to access legacy data by making use of common Web services through standardized protocols. In this way, Facade decouples layers so that they do not depend on each other which can make it easier to develop, to use and to promote code re-use.

== C# Example ==
using System;
using System.Collections.Generic; 
namespace DesignPatterns.Facade
{
public class OrderFacade
{
//Places an Order and Returns an Order ID
public int placeOrder(int CustomerID, List<BasketItem> Products)
{
Order anOrder = new Order();
OrderLine anOrderLine = new OrderLine();
Address DespatchAddress = Address.getCustomerDespatchAddress(CustomerID);
int OrderId = anOrder.requestOrderID();
anOrder.createOrder(OrderId, DespatchAddress);
anOrderLine.addOrderLinesToOrder(OrderId, Products);
return OrderId;
}
} 
//order class
public class Order
{
public int requestOrderID()
{
//Creates and Returns a Unique Order ID
} 
public void createOrder(int OrderId, Address DespatchAddress)
{
}
} 
//OrderLine Class
public class OrderLine
{
public void addOrderLinesToOrder(int OrderId, List<BasketItem> Products)
{
}
} 
//Public Customer
public class Address
{
public static Address getCustomerDespatchAddress(int CustomerID)
{
return new Address();
}
//Address properties
} 
public class BasketItem
{
//BasketItem Properties
}
}

=Adapter Pattern and Facade Pattern =

Adapter functions as a wrapper or modifier of an existing class. It provides a different or translated view of that class. 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. Reuse has always been painful and elusive. One reason has been the tribulation of designing something new, while reusing something old. There is always something not quite right between the old and the new. It may be physical dimensions or misalignment. It may be timing or synchronization. It may be unfortunate assumptions or competing standards. It is like the problem of inserting a new three-prong electrical plug in an old two-prong wall outlet – some kind of adapter or intermediary is necessary. 

Adapter is about creating an intermediary abstraction that translates, or maps, the old component to the new system. Clients call methods on the Adapter object which redirects them into calls to the legacy component. This strategy can be implemented either with inheritance or with aggregation. 

== Adapter Pattern Example ==
<pre>
interface Shape {
void draw(...);
}

Class LegacyLine {
void draw(..) { }
}

Class LegacyRectangle {
void draw(..) { }
}

Class Line implements Shape {
adapter = new LegacyLine();
void draw(...) {adapter.draw(...)}
}

Class Rectangle implements Shape {
adapter = new LegacyRectangle();
void draw(...) {adapter.draw(...)}
}
</pre>

In the example provided for the Facade pattern, the method placeOrder() uses the methods exposed by many other classes such as Order, OrderLine, Address etc to provide a high level view for the callers. The callers need not worry about the complexities in handling the sub-system. The users of the Class OrderFacade just invoke the method placeOrder() with the necessary arguments and rest of the process is taken care by placeOrder(). As can be seen in this case, a new method (placeOrder) was defined which has the logic and the necessary steps to handle all the sub-systems to create an order, create an id for the order, create a dispatch address etc.

In the example provided for the Adapter pattern, no new methods are defined. The existing method draw of LegacyRectangle is wrapped in a adapter class Rectangle. The methods in adapter classes does the necessary manipulations to the arguments and then passes to the original classes.

On similar lines, assume that the implementation and structure of BasketItem in Facade example needs to be changed. To handle such scenario, a new adapter class BasketItemAdapter is defined. It implements all the methods of the BasketItem and in each method makes necessary changes to the arguments and passes it to the new implementation as shown below.
== Example ==
<pre>
public Class BasketItemAdapter {
BasketItem newImplementation = new BasketItem();
void calculateCost(...) {
//make necessary modification
newImplementation.calculateCost(...);
}
}
</pre>

== Differences and similarities ==
* In both the Facade and Adapter pattern we have pre-existing classes.
* In the Facade, however, we do not have an interface we must design to, as we do in the Adapter pattern.
* We are not interested in polymorphic behavior<ref>[http://www.scribd.com/doc/2283673/Design-patterns-the-facade-and-adapter-pattern Scribd - Facade Design Pattern - http://www.scribd.com/doc/2283673/Design-patterns-the-facade-and-adapter-pattern]</ref> in the Facade, while in the Adapter, We probably am.(There are times when we just need to design to a particular API and therefore must use an Adapter)
* In the case of the Facade pattern, the motivation is to simplify the interface. With the Adapter, while simpler is better,We are trying to design to an existing interface and cannot simplify things even if a simpler interface were otherwise possible.

Bottom line is a Facade simplifies an interface while an Adapter converts the interface into a pre-existing interface.

=Abstract Factory Pattern and Facade Pattern =

Abstract factory pattern provides a level of indirection that abstracts the creation of families of related or dependent objects without directly specifying their concrete classes. The “factory” object has the responsibility for providing creation services for the entire platform family. Clients never create platform objects directly, they ask the factory to do that for them.

This mechanism makes exchanging product families easy because the specific class of the factory object appears only once in the application - where it is instantiated. The application can wholesale replace the entire family of products simply by instantiating a different concrete instance of the abstract factory. Because the service provided by the factory object is so pervasive, it is routinely implemented as a Singleton. 

== Abstract Factory Example ==
[[File:Abstract.JPG|600px|center]]

The AbstractFactory defines the interface that all of the concrete factories will need to implement in order to product Products. ConcreteFactoryA and ConcreteFactoryB have both implemented this interface here, creating two seperate families of product. Meanwhile, AbstractProductA and AbstractProductB are interfaces for the different types of product. Each factory will create one of each of these AbstractProducts.

The Client deals with AbstractFactory, AbstractProductA and AbstractProductB. It doesn't know anything about the implementations. The actual implementation of AbstractFactory that the Client uses is determined at runtime.

As you can see, one of the main benefits of this pattern is that the client is totally decoupled from the concrete products. Also, new product families can be easily added into the system, by just adding in a new type of ConcreteFactory that implements AbstractFactory, and creating the specific Product implementations.

== Facade Pattern Example ==

[[File:Facade-wo.JPG|300px|thumb|center|Without a Facade, the client has to deal with the intricacies of the sub system.]]

[[File:Facade-w.JPG|300px|thumb|center|With a Facade, the complexities of sub system are unified into a single interface making it readily usable for the client.]]

Considering the example for the Facade pattern, Client requires access to Employee objects, but in order to get that, it first need to contact the Database and retrieve the Company objects. It then retrieves Division objects from them and finally gains access to Employee objects. So, we see that It uses four classes and has to deal with complex details of the sub system. With Facade, the Client is shielded from most of the classes. It uses the Database Facade to retrieve Employee objects directly.

== Differences and similarities between Facade and Abstract Factory patterns ==
<ul>
<li>Facade is a structural design pattern whereas Abstract Factory pattern is a creational design pattern.
<li>Both are similar in a way that both provide an interface. Abstract Factory , provides kind of a Facade for creating products that belongs to its own factories.
<li>With the Abstract Factory Pattern we just provide a common factory builder for many different builders for the same thing. This can be used whenever we need to provide an interface to a set of builders meant to be used with something in common (the product) without bothering on what are we going to build or which factory are we going to use. The Facade pattern instead is used to provide a simple interface to a lot of different operations that the client classes should not see.
</ul>

Thus we see that both patterns achieve quite different goals. The facade pattern is used when you want to hide an implementation or it is about changing interface of some class or set of classes. On the other hand Abstarct factory pattern is used when you want to hide the details on constructing instances. Provide an interface for creating families of related or dependent objects without specifying their concrete classes.

=Mediator Pattern and Facade Pattern=
In Unix, permission to access system resources is managed at three levels of granularity: world, group, and owner. A group is a collection of users intended to model some functional affiliation. Each user on the system can be a member of one or more groups, and each group can have zero or more users assigned to it. Next figure shows three users that are assigned to all three groups. If we were to model this in software, we could decide to have User objects coupled to Group objects, and Group objects coupled to User objects. Then when changes occur, both classes and all their instances would be affected. An alternate approach would be to introduce “an additional level of indirection” - take the mapping of users to groups and groups to users, and make it an abstraction unto itself. This offers several advantages: Users and Groups are decoupled from one another, many mappings can easily be maintained and manipulated simultaneously, and the mapping abstraction can be extended in the future by defining derived classes. 

Partitioning a system into many objects generally enhances reusability, but proliferating interconnections between those objects tend to reduce it again. The mediator object: encapsulates all interconnections, acts as the hub of communication, is responsible for controlling and coordinating the interactions of its clients, and promotes loose coupling by keeping objects from referring to each other explicitly.

[[File:Mediator__1.gif]]

Colleagues (or peers) are not coupled to one another. Each talks to the Mediator, which in turn knows and conducts the orchestration of the others. The “many to many” mapping between colleagues that would otherwise exist, has been “promoted to full object status”. This new abstraction provides a locus of indirection where additional leverage can be hosted.

Mediator is similar to Facade in that it abstracts functionality of existing classes. Mediator abstracts/centralizes arbitrary communication between colleague objects, it routinely “adds value”, and it is known/referenced by the colleague objects (i.e. it defines a multidirectional protocol). In contrast, Facade defines a simpler interface to a subsystem, it doesn’t add new functionality, and it is not known by the subsystem classes (i.e. it defines a unidirectional protocol where it makes requests of the subsystem classes but not vice versa).

=References=
<references/>

== Additional Reading ==

* [http://java.dzone.com/articles/design-patterns-uncovered-1 Facade Pattern in Java] at java.dzone.com
* [http://www.cs.mcgill.ca/~hv/classes/CS400/01.hchen/doc/command/command.html Basics of Command Pattern]
* [http://www.dofactory.com/Patterns/PatternFacade.aspx Facade Pattern] at dofactory.com
* [http://www.dofactory.com/topic/1675/facade-with-factory-pattern.aspx Facade with Factory pattern] at dofactory.com
* [http://stackoverflow.com/questions/11188869/what-is-the-differences-between-facade-pattern-and-abstarct-factory-pattern.html difference between facade and abstract factory pattern] at stackoverflow.com
* [http://sourcemaking.com/design_patterns/command Behavorial Design Pattern - Command Pattern] at sourcemaking.com
* [http://www.coderanch.com/t/99780/patterns/Factory-Abstract-Factory-Pattern Facade
* [http://perfectjpattern.sourceforge.net/dp-command.html GoF Command Pattern]

* McDonald,J. 2008. Design Patterns

CSC/ECE 517 Fall 2012/ch2b 2w42 aa

2012-11-20T01:16:23Z

Aasawa: /* Differences and similarities */

=Introduction =

==Facade Pattern==
Intent 
* Provide a unified interface to a set of interfaces in a subsystem. 
* Wrap a complicated subsystem with a simpler interface. 

Facade discusses encapsulating a complex subsystem within a single interface object. This reduces the learning curve necessary to successfully leverage the subsystem. It also promotes decoupling the subsystem from its potentially many clients. On the other hand, if the Facade is the only access point for the subsystem, it will limit the features and flexibility that “power users” may need. The Facade object should be a fairly simple advocate or facilitator. It should not become an all-knowing oracle or “god” object. 

== Adapter Pattern ==

Intent 
* Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn’t otherwise because of incompatible interfaces. 
* Wrap an existing class with a new interface. 
* Impedance match an old component to a new system. 

Convert the interface of a class into another interface clients expect. Adapter lets classes worktogether that couldn't otherwise because of incompatible interfaces.

==Abstract Factory Pattern==

Intent 
* Provide an interface for creating families of related or dependent objects without specifying their concrete classes. 
* A hierarchy that encapsulates: many possible “platforms”, and the construction of a suite of “products”. 
* The new operator considered harmful. 

If an application is to be portable, it needs to encapsulate platform dependencies. These “platforms” might include: windowing system, operating system, database, etc. Too often, this encapsulatation is not engineered in advance, and lots of #ifdef case statements with options for all currently supported platforms begin to procreate like rabbits throughout the code. 

==Mediator Pattern==
Intent 

* Define an object that encapsulates how a set of objects interact. Mediator promotes loose coupling by keeping objects from referring to each other explicitly, and it lets you vary their interaction independently.
* Design an intermediary to decouple many peers.
* Promote the many-to-many relationships between interacting peers to “full object status”.

=Facade Pattern =

==Non-Software examples<ref>[http://aspalliance.com/970_Facade_Design_Pattern.2 ASPAlliance - Facade Design Pattern - http://aspalliance.com/970_Facade_Design_Pattern.2]</ref>==
In most of the Pizza centers, orders will be given through phone calls with the customer interacting with the Customer service representative. In this case, consumers do not have access to the Billing system, Kitchen and delivery department. The customer service representative acts as an interface and interacts with each of the departments involved in the transaction and ensures that Pizzas are delivered to the consumer. Customer Service representative corresponds to the facade. Individual departments involved in the transaction correspond to Sub-systems.

==Software examples==
Web Service Facade Solution Architecture provides an example for Facade design pattern. In this architectural solution, instead of rewriting legacy applications or customizing those with middleware to connect to other applications one by one, this solution helps create a "facade" for the legacy application. Other applications are easily "plugged into" this facade. By modeling a legacy application into its basic functions of create, read, update, and delete and then exposing these functions as Web methods, the Web service facade solution allows other applications to access legacy data by making use of common Web services through standardized protocols. In this way, Facade decouples layers so that they do not depend on each other which can make it easier to develop, to use and to promote code re-use.

== C# Example ==
using System;
using System.Collections.Generic; 
namespace DesignPatterns.Facade
{
public class OrderFacade
{
//Places an Order and Returns an Order ID
public int placeOrder(int CustomerID, List<BasketItem> Products)
{
Order anOrder = new Order();
OrderLine anOrderLine = new OrderLine();
Address DespatchAddress = Address.getCustomerDespatchAddress(CustomerID);
int OrderId = anOrder.requestOrderID();
anOrder.createOrder(OrderId, DespatchAddress);
anOrderLine.addOrderLinesToOrder(OrderId, Products);
return OrderId;
}
} 
//order class
public class Order
{
public int requestOrderID()
{
//Creates and Returns a Unique Order ID
} 
public void createOrder(int OrderId, Address DespatchAddress)
{
}
} 
//OrderLine Class
public class OrderLine
{
public void addOrderLinesToOrder(int OrderId, List<BasketItem> Products)
{
}
} 
//Public Customer
public class Address
{
public static Address getCustomerDespatchAddress(int CustomerID)
{
return new Address();
}
//Address properties
} 
public class BasketItem
{
//BasketItem Properties
}
}

=Adapter Pattern and Facade Pattern =

Adapter functions as a wrapper or modifier of an existing class. It provides a different or translated view of that class. 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. Reuse has always been painful and elusive. One reason has been the tribulation of designing something new, while reusing something old. There is always something not quite right between the old and the new. It may be physical dimensions or misalignment. It may be timing or synchronization. It may be unfortunate assumptions or competing standards. It is like the problem of inserting a new three-prong electrical plug in an old two-prong wall outlet – some kind of adapter or intermediary is necessary. 

Adapter is about creating an intermediary abstraction that translates, or maps, the old component to the new system. Clients call methods on the Adapter object which redirects them into calls to the legacy component. This strategy can be implemented either with inheritance or with aggregation. 

== Adapter Pattern Example ==
<pre>
interface Shape {
void draw(...);
}

Class LegacyLine {
void draw(..) { }
}

Class LegacyRectangle {
void draw(..) { }
}

Class Line implements Shape {
adapter = new LegacyLine();
void draw(...) {adapter.draw(...)}
}

Class Rectangle implements Shape {
adapter = new LegacyRectangle();
void draw(...) {adapter.draw(...)}
}
</pre>

In the example provided for the Facade pattern, the method placeOrder() uses the methods exposed by many other classes such as Order, OrderLine, Address etc to provide a high level view for the callers. The callers need not worry about the complexities in handling the sub-system. The users of the Class OrderFacade just invoke the method placeOrder() with the necessary arguments and rest of the process is taken care by placeOrder(). As can be seen in this case, a new method (placeOrder) was defined which has the logic and the necessary steps to handle all the sub-systems to create an order, create an id for the order, create a dispatch address etc.

In the example provided for the Adapter pattern, no new methods are defined. The existing method draw of LegacyRectangle is wrapped in a adapter class Rectangle. The methods in adapter classes does the necessary manipulations to the arguments and then passes to the original classes.

On similar lines, assume that the implementation and structure of BasketItem in Facade example needs to be changed. To handle such scenario, a new adapter class BasketItemAdapter is defined. It implements all the methods of the BasketItem and in each method makes necessary changes to the arguments and passes it to the new implementation as shown below.
== Example ==
<pre>
public Class BasketItemAdapter {
BasketItem newImplementation = new BasketItem();
void calculateCost(...) {
//make necessary modification
newImplementation.calculateCost(...);
}
}
</pre>

== Differences and similarities ==
* In both the Facade and Adapter pattern we have pre-existing classes.
* In the Facade, however, we do not have an interface we must design to, as we do in the Adapter pattern.
* We are not interested in polymorphic behavior<ref>[http://www.scribd.com/doc/2283673/Design-patterns-the-facade-and-adapter-pattern Scribd - Facade Design Pattern - http://www.scribd.com/doc/2283673/Design-patterns-the-facade-and-adapter-pattern]</ref> in the Facade, while in the Adapter, We probably am.(There are times when we just need to design to a particular API and therefore must use an Adapter)
* In the case of the Facade pattern, the motivation is to simplify the interface. With the Adapter, while simpler is better,We are trying to design to an existing interface and cannot simplify things even if a simpler interface were otherwise possible.

Bottom line is a Facade simplifies an interface while an Adapter converts the interface into a pre-existing interface.

=Abstract Factory Pattern and Facade Pattern =

Abstract factory pattern provides a level of indirection that abstracts the creation of families of related or dependent objects without directly specifying their concrete classes. The “factory” object has the responsibility for providing creation services for the entire platform family. Clients never create platform objects directly, they ask the factory to do that for them.

This mechanism makes exchanging product families easy because the specific class of the factory object appears only once in the application - where it is instantiated. The application can wholesale replace the entire family of products simply by instantiating a different concrete instance of the abstract factory. Because the service provided by the factory object is so pervasive, it is routinely implemented as a Singleton. 

== Abstract Factory Example ==
[[File:Abstract.JPG|600px|center]]

The AbstractFactory defines the interface that all of the concrete factories will need to implement in order to product Products. ConcreteFactoryA and ConcreteFactoryB have both implemented this interface here, creating two seperate families of product. Meanwhile, AbstractProductA and AbstractProductB are interfaces for the different types of product. Each factory will create one of each of these AbstractProducts.

The Client deals with AbstractFactory, AbstractProductA and AbstractProductB. It doesn't know anything about the implementations. The actual implementation of AbstractFactory that the Client uses is determined at runtime.

As you can see, one of the main benefits of this pattern is that the client is totally decoupled from the concrete products. Also, new product families can be easily added into the system, by just adding in a new type of ConcreteFactory that implements AbstractFactory, and creating the specific Product implementations.

== Facade Pattern Example ==

[[File:Facade-wo.JPG|300px|thumb|center|Without a Facade, the client has to deal with the intricacies of the sub system.]]

[[File:Facade-w.JPG|300px|thumb|center|With a Facade, the complexities of sub system are unified into a single interface making it readily usable for the client.]]

Considering the example for the Facade pattern, Client requires access to Employee objects, but in order to get that, it first need to contact the Database and retrieve the Company objects. It then retrieves Division objects from them and finally gains access to Employee objects. So, we see that It uses four classes and has to deal with complex details of the sub system. With Facade, the Client is shielded from most of the classes. It uses the Database Facade to retrieve Employee objects directly.

== Differences and similarities between Facade and Abstract Factory patterns ==
<ul>
<li>Facade is a structural design pattern whereas Abstract Factory pattern is a creational design pattern.
<li>Both are similar in a way that both provide an interface. Abstract Factory , provides kind of a Facade for creating products that belongs to its own factories.
<li>With the Abstract Factory Pattern we just provide a common factory builder for many different builders for the same thing. This can be used whenever we need to provide an interface to a set of builders meant to be used with something in common (the product) without bothering on what are we going to build or which factory are we going to use. The Facade pattern instead is used to provide a simple interface to a lot of different operations that the client classes should not see.
</ul>

Thus we see that both patterns achieve quite different goals. The facade pattern is used when you want to hide an implementation or it is about changing interface of some class or set of classes. On the other hand Abstarct factory pattern is used when you want to hide the details on constructing instances. Provide an interface for creating families of related or dependent objects without specifying their concrete classes.

=Mediator Pattern and Facade Pattern=
In Unix, permission to access system resources is managed at three levels of granularity: world, group, and owner. A group is a collection of users intended to model some functional affiliation. Each user on the system can be a member of one or more groups, and each group can have zero or more users assigned to it. Next figure shows three users that are assigned to all three groups. If we were to model this in software, we could decide to have User objects coupled to Group objects, and Group objects coupled to User objects. Then when changes occur, both classes and all their instances would be affected. An alternate approach would be to introduce “an additional level of indirection” - take the mapping of users to groups and groups to users, and make it an abstraction unto itself. This offers several advantages: Users and Groups are decoupled from one another, many mappings can easily be maintained and manipulated simultaneously, and the mapping abstraction can be extended in the future by defining derived classes. 

Partitioning a system into many objects generally enhances reusability, but proliferating interconnections between those objects tend to reduce it again. The mediator object: encapsulates all interconnections, acts as the hub of communication, is responsible for controlling and coordinating the interactions of its clients, and promotes loose coupling by keeping objects from referring to each other explicitly.

[[File:Mediator__1.gif]]

Colleagues (or peers) are not coupled to one another. Each talks to the Mediator, which in turn knows and conducts the orchestration of the others. The “many to many” mapping between colleagues that would otherwise exist, has been “promoted to full object status”. This new abstraction provides a locus of indirection where additional leverage can be hosted.

Mediator is similar to Facade in that it abstracts functionality of existing classes. Mediator abstracts/centralizes arbitrary communication between colleague objects, it routinely “adds value”, and it is known/referenced by the colleague objects (i.e. it defines a multidirectional protocol). In contrast, Facade defines a simpler interface to a subsystem, it doesn’t add new functionality, and it is not known by the subsystem classes (i.e. it defines a unidirectional protocol where it makes requests of the subsystem classes but not vice versa).

=References=
<references/>

== Additional Reading ==

* [http://java.dzone.com/articles/design-patterns-uncovered-1 Facade Pattern in Java] at java.dzone.com
* [http://www.cs.mcgill.ca/~hv/classes/CS400/01.hchen/doc/command/command.html Basics of Command Pattern]
* [http://www.dofactory.com/Patterns/PatternFacade.aspx Facade Pattern] at dofactory.com
* [http://www.dofactory.com/topic/1675/facade-with-factory-pattern.aspx Facade with Factory pattern] at dofactory.com
* [http://stackoverflow.com/questions/11188869/what-is-the-differences-between-facade-pattern-and-abstarct-factory-pattern.html difference between facade and abstract factory pattern] at stackoverflow.com
* [http://sourcemaking.com/design_patterns/command Behavorial Design Pattern - Command Pattern] at sourcemaking.com
* [http://www.coderanch.com/t/99780/patterns/Factory-Abstract-Factory-Pattern Facade
* [http://perfectjpattern.sourceforge.net/dp-command.html GoF Command Pattern]

* McDonald,J. 2008. Design Patterns

CSC/ECE 517 Fall 2012/ch2b 2w42 aa

2012-11-20T01:15:26Z

Aasawa: /* Differences and similaritieshttp://www.scribd.com/doc/2283673/Design-patterns-the-facade-and-adapter-pattern */

=Introduction =

==Facade Pattern==
Intent 
* Provide a unified interface to a set of interfaces in a subsystem. 
* Wrap a complicated subsystem with a simpler interface. 

Facade discusses encapsulating a complex subsystem within a single interface object. This reduces the learning curve necessary to successfully leverage the subsystem. It also promotes decoupling the subsystem from its potentially many clients. On the other hand, if the Facade is the only access point for the subsystem, it will limit the features and flexibility that “power users” may need. The Facade object should be a fairly simple advocate or facilitator. It should not become an all-knowing oracle or “god” object. 

== Adapter Pattern ==

Intent 
* Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn’t otherwise because of incompatible interfaces. 
* Wrap an existing class with a new interface. 
* Impedance match an old component to a new system. 

Convert the interface of a class into another interface clients expect. Adapter lets classes worktogether that couldn't otherwise because of incompatible interfaces.

==Abstract Factory Pattern==

Intent 
* Provide an interface for creating families of related or dependent objects without specifying their concrete classes. 
* A hierarchy that encapsulates: many possible “platforms”, and the construction of a suite of “products”. 
* The new operator considered harmful. 

If an application is to be portable, it needs to encapsulate platform dependencies. These “platforms” might include: windowing system, operating system, database, etc. Too often, this encapsulatation is not engineered in advance, and lots of #ifdef case statements with options for all currently supported platforms begin to procreate like rabbits throughout the code. 

==Mediator Pattern==
Intent 

* Define an object that encapsulates how a set of objects interact. Mediator promotes loose coupling by keeping objects from referring to each other explicitly, and it lets you vary their interaction independently.
* Design an intermediary to decouple many peers.
* Promote the many-to-many relationships between interacting peers to “full object status”.

=Facade Pattern =

==Non-Software examples<ref>[http://aspalliance.com/970_Facade_Design_Pattern.2 ASPAlliance - Facade Design Pattern - http://aspalliance.com/970_Facade_Design_Pattern.2]</ref>==
In most of the Pizza centers, orders will be given through phone calls with the customer interacting with the Customer service representative. In this case, consumers do not have access to the Billing system, Kitchen and delivery department. The customer service representative acts as an interface and interacts with each of the departments involved in the transaction and ensures that Pizzas are delivered to the consumer. Customer Service representative corresponds to the facade. Individual departments involved in the transaction correspond to Sub-systems.

==Software examples==
Web Service Facade Solution Architecture provides an example for Facade design pattern. In this architectural solution, instead of rewriting legacy applications or customizing those with middleware to connect to other applications one by one, this solution helps create a "facade" for the legacy application. Other applications are easily "plugged into" this facade. By modeling a legacy application into its basic functions of create, read, update, and delete and then exposing these functions as Web methods, the Web service facade solution allows other applications to access legacy data by making use of common Web services through standardized protocols. In this way, Facade decouples layers so that they do not depend on each other which can make it easier to develop, to use and to promote code re-use.

== C# Example ==
using System;
using System.Collections.Generic; 
namespace DesignPatterns.Facade
{
public class OrderFacade
{
//Places an Order and Returns an Order ID
public int placeOrder(int CustomerID, List<BasketItem> Products)
{
Order anOrder = new Order();
OrderLine anOrderLine = new OrderLine();
Address DespatchAddress = Address.getCustomerDespatchAddress(CustomerID);
int OrderId = anOrder.requestOrderID();
anOrder.createOrder(OrderId, DespatchAddress);
anOrderLine.addOrderLinesToOrder(OrderId, Products);
return OrderId;
}
} 
//order class
public class Order
{
public int requestOrderID()
{
//Creates and Returns a Unique Order ID
} 
public void createOrder(int OrderId, Address DespatchAddress)
{
}
} 
//OrderLine Class
public class OrderLine
{
public void addOrderLinesToOrder(int OrderId, List<BasketItem> Products)
{
}
} 
//Public Customer
public class Address
{
public static Address getCustomerDespatchAddress(int CustomerID)
{
return new Address();
}
//Address properties
} 
public class BasketItem
{
//BasketItem Properties
}
}

=Adapter Pattern and Facade Pattern =

Adapter functions as a wrapper or modifier of an existing class. It provides a different or translated view of that class. 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. Reuse has always been painful and elusive. One reason has been the tribulation of designing something new, while reusing something old. There is always something not quite right between the old and the new. It may be physical dimensions or misalignment. It may be timing or synchronization. It may be unfortunate assumptions or competing standards. It is like the problem of inserting a new three-prong electrical plug in an old two-prong wall outlet – some kind of adapter or intermediary is necessary. 

Adapter is about creating an intermediary abstraction that translates, or maps, the old component to the new system. Clients call methods on the Adapter object which redirects them into calls to the legacy component. This strategy can be implemented either with inheritance or with aggregation. 

== Adapter Pattern Example ==
<pre>
interface Shape {
void draw(...);
}

Class LegacyLine {
void draw(..) { }
}

Class LegacyRectangle {
void draw(..) { }
}

Class Line implements Shape {
adapter = new LegacyLine();
void draw(...) {adapter.draw(...)}
}

Class Rectangle implements Shape {
adapter = new LegacyRectangle();
void draw(...) {adapter.draw(...)}
}
</pre>

In the example provided for the Facade pattern, the method placeOrder() uses the methods exposed by many other classes such as Order, OrderLine, Address etc to provide a high level view for the callers. The callers need not worry about the complexities in handling the sub-system. The users of the Class OrderFacade just invoke the method placeOrder() with the necessary arguments and rest of the process is taken care by placeOrder(). As can be seen in this case, a new method (placeOrder) was defined which has the logic and the necessary steps to handle all the sub-systems to create an order, create an id for the order, create a dispatch address etc.

In the example provided for the Adapter pattern, no new methods are defined. The existing method draw of LegacyRectangle is wrapped in a adapter class Rectangle. The methods in adapter classes does the necessary manipulations to the arguments and then passes to the original classes.

On similar lines, assume that the implementation and structure of BasketItem in Facade example needs to be changed. To handle such scenario, a new adapter class BasketItemAdapter is defined. It implements all the methods of the BasketItem and in each method makes necessary changes to the arguments and passes it to the new implementation as shown below.
== Example ==
<pre>
public Class BasketItemAdapter {
BasketItem newImplementation = new BasketItem();
void calculateCost(...) {
//make necessary modification
newImplementation.calculateCost(...);
}
}
</pre>

== Differences and similarities ==
* In both the Facade and Adapter pattern we have pre-existing classes.
* In the Facade, however, we do not have an interface we must design to, as we do in the Adapter pattern.
* We are not interested in polymorphic behavior<ref>[http://www.scribd.com/doc/2283673/Design-patterns-the-facade-and-adapter-pattern ASPAlliance - Facade Design Pattern - http://www.scribd.com/doc/2283673/Design-patterns-the-facade-and-adapter-pattern]</ref> in the Facade, while in the Adapter, We probably am.(There are times when we just need to design to a particular API and therefore must use an Adapter)
* In the case of the Facade pattern, the motivation is to simplify the interface. With the Adapter, while simpler is better,We are trying to design to an existing interface and cannot simplify things even if a simpler interface were otherwise possible.

Bottom line is a Facade simplifies an interface while an Adapter converts the interface into a pre-existing interface.

=Abstract Factory Pattern and Facade Pattern =

Abstract factory pattern provides a level of indirection that abstracts the creation of families of related or dependent objects without directly specifying their concrete classes. The “factory” object has the responsibility for providing creation services for the entire platform family. Clients never create platform objects directly, they ask the factory to do that for them.

This mechanism makes exchanging product families easy because the specific class of the factory object appears only once in the application - where it is instantiated. The application can wholesale replace the entire family of products simply by instantiating a different concrete instance of the abstract factory. Because the service provided by the factory object is so pervasive, it is routinely implemented as a Singleton. 

== Abstract Factory Example ==
[[File:Abstract.JPG|600px|center]]

The AbstractFactory defines the interface that all of the concrete factories will need to implement in order to product Products. ConcreteFactoryA and ConcreteFactoryB have both implemented this interface here, creating two seperate families of product. Meanwhile, AbstractProductA and AbstractProductB are interfaces for the different types of product. Each factory will create one of each of these AbstractProducts.

The Client deals with AbstractFactory, AbstractProductA and AbstractProductB. It doesn't know anything about the implementations. The actual implementation of AbstractFactory that the Client uses is determined at runtime.

As you can see, one of the main benefits of this pattern is that the client is totally decoupled from the concrete products. Also, new product families can be easily added into the system, by just adding in a new type of ConcreteFactory that implements AbstractFactory, and creating the specific Product implementations.

== Facade Pattern Example ==

[[File:Facade-wo.JPG|300px|thumb|center|Without a Facade, the client has to deal with the intricacies of the sub system.]]

[[File:Facade-w.JPG|300px|thumb|center|With a Facade, the complexities of sub system are unified into a single interface making it readily usable for the client.]]

Considering the example for the Facade pattern, Client requires access to Employee objects, but in order to get that, it first need to contact the Database and retrieve the Company objects. It then retrieves Division objects from them and finally gains access to Employee objects. So, we see that It uses four classes and has to deal with complex details of the sub system. With Facade, the Client is shielded from most of the classes. It uses the Database Facade to retrieve Employee objects directly.

== Differences and similarities between Facade and Abstract Factory patterns ==
<ul>
<li>Facade is a structural design pattern whereas Abstract Factory pattern is a creational design pattern.
<li>Both are similar in a way that both provide an interface. Abstract Factory , provides kind of a Facade for creating products that belongs to its own factories.
<li>With the Abstract Factory Pattern we just provide a common factory builder for many different builders for the same thing. This can be used whenever we need to provide an interface to a set of builders meant to be used with something in common (the product) without bothering on what are we going to build or which factory are we going to use. The Facade pattern instead is used to provide a simple interface to a lot of different operations that the client classes should not see.
</ul>

Thus we see that both patterns achieve quite different goals. The facade pattern is used when you want to hide an implementation or it is about changing interface of some class or set of classes. On the other hand Abstarct factory pattern is used when you want to hide the details on constructing instances. Provide an interface for creating families of related or dependent objects without specifying their concrete classes.

=Mediator Pattern and Facade Pattern=
In Unix, permission to access system resources is managed at three levels of granularity: world, group, and owner. A group is a collection of users intended to model some functional affiliation. Each user on the system can be a member of one or more groups, and each group can have zero or more users assigned to it. Next figure shows three users that are assigned to all three groups. If we were to model this in software, we could decide to have User objects coupled to Group objects, and Group objects coupled to User objects. Then when changes occur, both classes and all their instances would be affected. An alternate approach would be to introduce “an additional level of indirection” - take the mapping of users to groups and groups to users, and make it an abstraction unto itself. This offers several advantages: Users and Groups are decoupled from one another, many mappings can easily be maintained and manipulated simultaneously, and the mapping abstraction can be extended in the future by defining derived classes. 

Partitioning a system into many objects generally enhances reusability, but proliferating interconnections between those objects tend to reduce it again. The mediator object: encapsulates all interconnections, acts as the hub of communication, is responsible for controlling and coordinating the interactions of its clients, and promotes loose coupling by keeping objects from referring to each other explicitly.

[[File:Mediator__1.gif]]

Colleagues (or peers) are not coupled to one another. Each talks to the Mediator, which in turn knows and conducts the orchestration of the others. The “many to many” mapping between colleagues that would otherwise exist, has been “promoted to full object status”. This new abstraction provides a locus of indirection where additional leverage can be hosted.

Mediator is similar to Facade in that it abstracts functionality of existing classes. Mediator abstracts/centralizes arbitrary communication between colleague objects, it routinely “adds value”, and it is known/referenced by the colleague objects (i.e. it defines a multidirectional protocol). In contrast, Facade defines a simpler interface to a subsystem, it doesn’t add new functionality, and it is not known by the subsystem classes (i.e. it defines a unidirectional protocol where it makes requests of the subsystem classes but not vice versa).

=References=
<references/>

== Additional Reading ==

* [http://java.dzone.com/articles/design-patterns-uncovered-1 Facade Pattern in Java] at java.dzone.com
* [http://www.cs.mcgill.ca/~hv/classes/CS400/01.hchen/doc/command/command.html Basics of Command Pattern]
* [http://www.dofactory.com/Patterns/PatternFacade.aspx Facade Pattern] at dofactory.com
* [http://www.dofactory.com/topic/1675/facade-with-factory-pattern.aspx Facade with Factory pattern] at dofactory.com
* [http://stackoverflow.com/questions/11188869/what-is-the-differences-between-facade-pattern-and-abstarct-factory-pattern.html difference between facade and abstract factory pattern] at stackoverflow.com
* [http://sourcemaking.com/design_patterns/command Behavorial Design Pattern - Command Pattern] at sourcemaking.com
* [http://www.coderanch.com/t/99780/patterns/Factory-Abstract-Factory-Pattern Facade
* [http://perfectjpattern.sourceforge.net/dp-command.html GoF Command Pattern]

* McDonald,J. 2008. Design Patterns

CSC/ECE 517 Fall 2012/ch2b 2w42 aa

2012-11-20T01:13:46Z

Aasawa: /* Differences and similarities */

=Introduction =

==Facade Pattern==
Intent 
* Provide a unified interface to a set of interfaces in a subsystem. 
* Wrap a complicated subsystem with a simpler interface. 

Facade discusses encapsulating a complex subsystem within a single interface object. This reduces the learning curve necessary to successfully leverage the subsystem. It also promotes decoupling the subsystem from its potentially many clients. On the other hand, if the Facade is the only access point for the subsystem, it will limit the features and flexibility that “power users” may need. The Facade object should be a fairly simple advocate or facilitator. It should not become an all-knowing oracle or “god” object. 

== Adapter Pattern ==

Intent 
* Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn’t otherwise because of incompatible interfaces. 
* Wrap an existing class with a new interface. 
* Impedance match an old component to a new system. 

Convert the interface of a class into another interface clients expect. Adapter lets classes worktogether that couldn't otherwise because of incompatible interfaces.

==Abstract Factory Pattern==

Intent 
* Provide an interface for creating families of related or dependent objects without specifying their concrete classes. 
* A hierarchy that encapsulates: many possible “platforms”, and the construction of a suite of “products”. 
* The new operator considered harmful. 

If an application is to be portable, it needs to encapsulate platform dependencies. These “platforms” might include: windowing system, operating system, database, etc. Too often, this encapsulatation is not engineered in advance, and lots of #ifdef case statements with options for all currently supported platforms begin to procreate like rabbits throughout the code. 

==Mediator Pattern==
Intent 

* Define an object that encapsulates how a set of objects interact. Mediator promotes loose coupling by keeping objects from referring to each other explicitly, and it lets you vary their interaction independently.
* Design an intermediary to decouple many peers.
* Promote the many-to-many relationships between interacting peers to “full object status”.

=Facade Pattern =

==Non-Software examples<ref>[http://aspalliance.com/970_Facade_Design_Pattern.2 ASPAlliance - Facade Design Pattern - http://aspalliance.com/970_Facade_Design_Pattern.2]</ref>==
In most of the Pizza centers, orders will be given through phone calls with the customer interacting with the Customer service representative. In this case, consumers do not have access to the Billing system, Kitchen and delivery department. The customer service representative acts as an interface and interacts with each of the departments involved in the transaction and ensures that Pizzas are delivered to the consumer. Customer Service representative corresponds to the facade. Individual departments involved in the transaction correspond to Sub-systems.

==Software examples==
Web Service Facade Solution Architecture provides an example for Facade design pattern. In this architectural solution, instead of rewriting legacy applications or customizing those with middleware to connect to other applications one by one, this solution helps create a "facade" for the legacy application. Other applications are easily "plugged into" this facade. By modeling a legacy application into its basic functions of create, read, update, and delete and then exposing these functions as Web methods, the Web service facade solution allows other applications to access legacy data by making use of common Web services through standardized protocols. In this way, Facade decouples layers so that they do not depend on each other which can make it easier to develop, to use and to promote code re-use.

== C# Example ==
using System;
using System.Collections.Generic; 
namespace DesignPatterns.Facade
{
public class OrderFacade
{
//Places an Order and Returns an Order ID
public int placeOrder(int CustomerID, List<BasketItem> Products)
{
Order anOrder = new Order();
OrderLine anOrderLine = new OrderLine();
Address DespatchAddress = Address.getCustomerDespatchAddress(CustomerID);
int OrderId = anOrder.requestOrderID();
anOrder.createOrder(OrderId, DespatchAddress);
anOrderLine.addOrderLinesToOrder(OrderId, Products);
return OrderId;
}
} 
//order class
public class Order
{
public int requestOrderID()
{
//Creates and Returns a Unique Order ID
} 
public void createOrder(int OrderId, Address DespatchAddress)
{
}
} 
//OrderLine Class
public class OrderLine
{
public void addOrderLinesToOrder(int OrderId, List<BasketItem> Products)
{
}
} 
//Public Customer
public class Address
{
public static Address getCustomerDespatchAddress(int CustomerID)
{
return new Address();
}
//Address properties
} 
public class BasketItem
{
//BasketItem Properties
}
}

=Adapter Pattern and Facade Pattern =

Adapter functions as a wrapper or modifier of an existing class. It provides a different or translated view of that class. 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. Reuse has always been painful and elusive. One reason has been the tribulation of designing something new, while reusing something old. There is always something not quite right between the old and the new. It may be physical dimensions or misalignment. It may be timing or synchronization. It may be unfortunate assumptions or competing standards. It is like the problem of inserting a new three-prong electrical plug in an old two-prong wall outlet – some kind of adapter or intermediary is necessary. 

Adapter is about creating an intermediary abstraction that translates, or maps, the old component to the new system. Clients call methods on the Adapter object which redirects them into calls to the legacy component. This strategy can be implemented either with inheritance or with aggregation. 

== Adapter Pattern Example ==
<pre>
interface Shape {
void draw(...);
}

Class LegacyLine {
void draw(..) { }
}

Class LegacyRectangle {
void draw(..) { }
}

Class Line implements Shape {
adapter = new LegacyLine();
void draw(...) {adapter.draw(...)}
}

Class Rectangle implements Shape {
adapter = new LegacyRectangle();
void draw(...) {adapter.draw(...)}
}
</pre>

In the example provided for the Facade pattern, the method placeOrder() uses the methods exposed by many other classes such as Order, OrderLine, Address etc to provide a high level view for the callers. The callers need not worry about the complexities in handling the sub-system. The users of the Class OrderFacade just invoke the method placeOrder() with the necessary arguments and rest of the process is taken care by placeOrder(). As can be seen in this case, a new method (placeOrder) was defined which has the logic and the necessary steps to handle all the sub-systems to create an order, create an id for the order, create a dispatch address etc.

In the example provided for the Adapter pattern, no new methods are defined. The existing method draw of LegacyRectangle is wrapped in a adapter class Rectangle. The methods in adapter classes does the necessary manipulations to the arguments and then passes to the original classes.

On similar lines, assume that the implementation and structure of BasketItem in Facade example needs to be changed. To handle such scenario, a new adapter class BasketItemAdapter is defined. It implements all the methods of the BasketItem and in each method makes necessary changes to the arguments and passes it to the new implementation as shown below.
== Example ==
<pre>
public Class BasketItemAdapter {
BasketItem newImplementation = new BasketItem();
void calculateCost(...) {
//make necessary modification
newImplementation.calculateCost(...);
}
}
</pre>

== Differences and similaritieshttp://www.scribd.com/doc/2283673/Design-patterns-the-facade-and-adapter-pattern ==
* In both the Facade and Adapter pattern we have pre-existing classes.
* In the Facade, however, we do not have an interface we must design to, as we do in the Adapter pattern.
* We are not interested in polymorphic behavior in the Facade, while in the Adapter, We probably am.(There are times when we just need to design to a particular API and therefore must use an Adapter)
* In the case of the Facade pattern, the motivation is to simplify the interface. With the Adapter, while simpler is better,We are trying to design to an existing interface and cannot simplify things even if a simpler interface were otherwise possible.

Bottom line is a Facade simplifies an interface while an Adapter converts the interface into a pre-existing interface.

=Abstract Factory Pattern and Facade Pattern =

Abstract factory pattern provides a level of indirection that abstracts the creation of families of related or dependent objects without directly specifying their concrete classes. The “factory” object has the responsibility for providing creation services for the entire platform family. Clients never create platform objects directly, they ask the factory to do that for them.

This mechanism makes exchanging product families easy because the specific class of the factory object appears only once in the application - where it is instantiated. The application can wholesale replace the entire family of products simply by instantiating a different concrete instance of the abstract factory. Because the service provided by the factory object is so pervasive, it is routinely implemented as a Singleton. 

== Abstract Factory Example ==
[[File:Abstract.JPG|600px|center]]

The AbstractFactory defines the interface that all of the concrete factories will need to implement in order to product Products. ConcreteFactoryA and ConcreteFactoryB have both implemented this interface here, creating two seperate families of product. Meanwhile, AbstractProductA and AbstractProductB are interfaces for the different types of product. Each factory will create one of each of these AbstractProducts.

The Client deals with AbstractFactory, AbstractProductA and AbstractProductB. It doesn't know anything about the implementations. The actual implementation of AbstractFactory that the Client uses is determined at runtime.

As you can see, one of the main benefits of this pattern is that the client is totally decoupled from the concrete products. Also, new product families can be easily added into the system, by just adding in a new type of ConcreteFactory that implements AbstractFactory, and creating the specific Product implementations.

== Facade Pattern Example ==

[[File:Facade-wo.JPG|300px|thumb|center|Without a Facade, the client has to deal with the intricacies of the sub system.]]

[[File:Facade-w.JPG|300px|thumb|center|With a Facade, the complexities of sub system are unified into a single interface making it readily usable for the client.]]

Considering the example for the Facade pattern, Client requires access to Employee objects, but in order to get that, it first need to contact the Database and retrieve the Company objects. It then retrieves Division objects from them and finally gains access to Employee objects. So, we see that It uses four classes and has to deal with complex details of the sub system. With Facade, the Client is shielded from most of the classes. It uses the Database Facade to retrieve Employee objects directly.

== Differences and similarities between Facade and Abstract Factory patterns ==
<ul>
<li>Facade is a structural design pattern whereas Abstract Factory pattern is a creational design pattern.
<li>Both are similar in a way that both provide an interface. Abstract Factory , provides kind of a Facade for creating products that belongs to its own factories.
<li>With the Abstract Factory Pattern we just provide a common factory builder for many different builders for the same thing. This can be used whenever we need to provide an interface to a set of builders meant to be used with something in common (the product) without bothering on what are we going to build or which factory are we going to use. The Facade pattern instead is used to provide a simple interface to a lot of different operations that the client classes should not see.
</ul>

Thus we see that both patterns achieve quite different goals. The facade pattern is used when you want to hide an implementation or it is about changing interface of some class or set of classes. On the other hand Abstarct factory pattern is used when you want to hide the details on constructing instances. Provide an interface for creating families of related or dependent objects without specifying their concrete classes.

=Mediator Pattern and Facade Pattern=
In Unix, permission to access system resources is managed at three levels of granularity: world, group, and owner. A group is a collection of users intended to model some functional affiliation. Each user on the system can be a member of one or more groups, and each group can have zero or more users assigned to it. Next figure shows three users that are assigned to all three groups. If we were to model this in software, we could decide to have User objects coupled to Group objects, and Group objects coupled to User objects. Then when changes occur, both classes and all their instances would be affected. An alternate approach would be to introduce “an additional level of indirection” - take the mapping of users to groups and groups to users, and make it an abstraction unto itself. This offers several advantages: Users and Groups are decoupled from one another, many mappings can easily be maintained and manipulated simultaneously, and the mapping abstraction can be extended in the future by defining derived classes. 

Partitioning a system into many objects generally enhances reusability, but proliferating interconnections between those objects tend to reduce it again. The mediator object: encapsulates all interconnections, acts as the hub of communication, is responsible for controlling and coordinating the interactions of its clients, and promotes loose coupling by keeping objects from referring to each other explicitly.

[[File:Mediator__1.gif]]

Colleagues (or peers) are not coupled to one another. Each talks to the Mediator, which in turn knows and conducts the orchestration of the others. The “many to many” mapping between colleagues that would otherwise exist, has been “promoted to full object status”. This new abstraction provides a locus of indirection where additional leverage can be hosted.

Mediator is similar to Facade in that it abstracts functionality of existing classes. Mediator abstracts/centralizes arbitrary communication between colleague objects, it routinely “adds value”, and it is known/referenced by the colleague objects (i.e. it defines a multidirectional protocol). In contrast, Facade defines a simpler interface to a subsystem, it doesn’t add new functionality, and it is not known by the subsystem classes (i.e. it defines a unidirectional protocol where it makes requests of the subsystem classes but not vice versa).

=References=
<references/>

== Additional Reading ==

* [http://java.dzone.com/articles/design-patterns-uncovered-1 Facade Pattern in Java] at java.dzone.com
* [http://www.cs.mcgill.ca/~hv/classes/CS400/01.hchen/doc/command/command.html Basics of Command Pattern]
* [http://www.dofactory.com/Patterns/PatternFacade.aspx Facade Pattern] at dofactory.com
* [http://www.dofactory.com/topic/1675/facade-with-factory-pattern.aspx Facade with Factory pattern] at dofactory.com
* [http://stackoverflow.com/questions/11188869/what-is-the-differences-between-facade-pattern-and-abstarct-factory-pattern.html difference between facade and abstract factory pattern] at stackoverflow.com
* [http://sourcemaking.com/design_patterns/command Behavorial Design Pattern - Command Pattern] at sourcemaking.com
* [http://www.coderanch.com/t/99780/patterns/Factory-Abstract-Factory-Pattern Facade
* [http://perfectjpattern.sourceforge.net/dp-command.html GoF Command Pattern]

* McDonald,J. 2008. Design Patterns

CSC/ECE 517 Fall 2012/ch2b 2w42 aa

2012-11-20T01:13:06Z

Aasawa: /* Additional Reading */

=Introduction =

==Facade Pattern==
Intent 
* Provide a unified interface to a set of interfaces in a subsystem. 
* Wrap a complicated subsystem with a simpler interface. 

Facade discusses encapsulating a complex subsystem within a single interface object. This reduces the learning curve necessary to successfully leverage the subsystem. It also promotes decoupling the subsystem from its potentially many clients. On the other hand, if the Facade is the only access point for the subsystem, it will limit the features and flexibility that “power users” may need. The Facade object should be a fairly simple advocate or facilitator. It should not become an all-knowing oracle or “god” object. 

== Adapter Pattern ==

Intent 
* Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn’t otherwise because of incompatible interfaces. 
* Wrap an existing class with a new interface. 
* Impedance match an old component to a new system. 

Convert the interface of a class into another interface clients expect. Adapter lets classes worktogether that couldn't otherwise because of incompatible interfaces.

==Abstract Factory Pattern==

Intent 
* Provide an interface for creating families of related or dependent objects without specifying their concrete classes. 
* A hierarchy that encapsulates: many possible “platforms”, and the construction of a suite of “products”. 
* The new operator considered harmful. 

If an application is to be portable, it needs to encapsulate platform dependencies. These “platforms” might include: windowing system, operating system, database, etc. Too often, this encapsulatation is not engineered in advance, and lots of #ifdef case statements with options for all currently supported platforms begin to procreate like rabbits throughout the code. 

==Mediator Pattern==
Intent 

* Define an object that encapsulates how a set of objects interact. Mediator promotes loose coupling by keeping objects from referring to each other explicitly, and it lets you vary their interaction independently.
* Design an intermediary to decouple many peers.
* Promote the many-to-many relationships between interacting peers to “full object status”.

=Facade Pattern =

==Non-Software examples<ref>[http://aspalliance.com/970_Facade_Design_Pattern.2 ASPAlliance - Facade Design Pattern - http://aspalliance.com/970_Facade_Design_Pattern.2]</ref>==
In most of the Pizza centers, orders will be given through phone calls with the customer interacting with the Customer service representative. In this case, consumers do not have access to the Billing system, Kitchen and delivery department. The customer service representative acts as an interface and interacts with each of the departments involved in the transaction and ensures that Pizzas are delivered to the consumer. Customer Service representative corresponds to the facade. Individual departments involved in the transaction correspond to Sub-systems.

==Software examples==
Web Service Facade Solution Architecture provides an example for Facade design pattern. In this architectural solution, instead of rewriting legacy applications or customizing those with middleware to connect to other applications one by one, this solution helps create a "facade" for the legacy application. Other applications are easily "plugged into" this facade. By modeling a legacy application into its basic functions of create, read, update, and delete and then exposing these functions as Web methods, the Web service facade solution allows other applications to access legacy data by making use of common Web services through standardized protocols. In this way, Facade decouples layers so that they do not depend on each other which can make it easier to develop, to use and to promote code re-use.

== C# Example ==
using System;
using System.Collections.Generic; 
namespace DesignPatterns.Facade
{
public class OrderFacade
{
//Places an Order and Returns an Order ID
public int placeOrder(int CustomerID, List<BasketItem> Products)
{
Order anOrder = new Order();
OrderLine anOrderLine = new OrderLine();
Address DespatchAddress = Address.getCustomerDespatchAddress(CustomerID);
int OrderId = anOrder.requestOrderID();
anOrder.createOrder(OrderId, DespatchAddress);
anOrderLine.addOrderLinesToOrder(OrderId, Products);
return OrderId;
}
} 
//order class
public class Order
{
public int requestOrderID()
{
//Creates and Returns a Unique Order ID
} 
public void createOrder(int OrderId, Address DespatchAddress)
{
}
} 
//OrderLine Class
public class OrderLine
{
public void addOrderLinesToOrder(int OrderId, List<BasketItem> Products)
{
}
} 
//Public Customer
public class Address
{
public static Address getCustomerDespatchAddress(int CustomerID)
{
return new Address();
}
//Address properties
} 
public class BasketItem
{
//BasketItem Properties
}
}

=Adapter Pattern and Facade Pattern =

Adapter functions as a wrapper or modifier of an existing class. It provides a different or translated view of that class. 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. Reuse has always been painful and elusive. One reason has been the tribulation of designing something new, while reusing something old. There is always something not quite right between the old and the new. It may be physical dimensions or misalignment. It may be timing or synchronization. It may be unfortunate assumptions or competing standards. It is like the problem of inserting a new three-prong electrical plug in an old two-prong wall outlet – some kind of adapter or intermediary is necessary. 

Adapter is about creating an intermediary abstraction that translates, or maps, the old component to the new system. Clients call methods on the Adapter object which redirects them into calls to the legacy component. This strategy can be implemented either with inheritance or with aggregation. 

== Adapter Pattern Example ==
<pre>
interface Shape {
void draw(...);
}

Class LegacyLine {
void draw(..) { }
}

Class LegacyRectangle {
void draw(..) { }
}

Class Line implements Shape {
adapter = new LegacyLine();
void draw(...) {adapter.draw(...)}
}

Class Rectangle implements Shape {
adapter = new LegacyRectangle();
void draw(...) {adapter.draw(...)}
}
</pre>

In the example provided for the Facade pattern, the method placeOrder() uses the methods exposed by many other classes such as Order, OrderLine, Address etc to provide a high level view for the callers. The callers need not worry about the complexities in handling the sub-system. The users of the Class OrderFacade just invoke the method placeOrder() with the necessary arguments and rest of the process is taken care by placeOrder(). As can be seen in this case, a new method (placeOrder) was defined which has the logic and the necessary steps to handle all the sub-systems to create an order, create an id for the order, create a dispatch address etc.

In the example provided for the Adapter pattern, no new methods are defined. The existing method draw of LegacyRectangle is wrapped in a adapter class Rectangle. The methods in adapter classes does the necessary manipulations to the arguments and then passes to the original classes.

On similar lines, assume that the implementation and structure of BasketItem in Facade example needs to be changed. To handle such scenario, a new adapter class BasketItemAdapter is defined. It implements all the methods of the BasketItem and in each method makes necessary changes to the arguments and passes it to the new implementation as shown below.
== Example ==
<pre>
public Class BasketItemAdapter {
BasketItem newImplementation = new BasketItem();
void calculateCost(...) {
//make necessary modification
newImplementation.calculateCost(...);
}
}
</pre>

== Differences and similarities ==
* In both the Facade and Adapter pattern we have pre-existing classes.
* In the Facade, however, we do not have an interface we must design to, as we do in the Adapter pattern.
* We are not interested in polymorphic behavior in the Facade, while in the Adapter, We probably am.(There are times when we just need to design to a particular API and therefore must use an Adapter)
* In the case of the Facade pattern, the motivation is to simplify the interface. With the Adapter, while simpler is better,We are trying to design to an existing interface and cannot simplify things even if a simpler interface were otherwise possible.

Bottom line is a Facade simplifies an interface while an Adapter converts the interface into a pre-existing interface.

=Abstract Factory Pattern and Facade Pattern =

Abstract factory pattern provides a level of indirection that abstracts the creation of families of related or dependent objects without directly specifying their concrete classes. The “factory” object has the responsibility for providing creation services for the entire platform family. Clients never create platform objects directly, they ask the factory to do that for them.

This mechanism makes exchanging product families easy because the specific class of the factory object appears only once in the application - where it is instantiated. The application can wholesale replace the entire family of products simply by instantiating a different concrete instance of the abstract factory. Because the service provided by the factory object is so pervasive, it is routinely implemented as a Singleton. 

== Abstract Factory Example ==
[[File:Abstract.JPG|600px|center]]

The AbstractFactory defines the interface that all of the concrete factories will need to implement in order to product Products. ConcreteFactoryA and ConcreteFactoryB have both implemented this interface here, creating two seperate families of product. Meanwhile, AbstractProductA and AbstractProductB are interfaces for the different types of product. Each factory will create one of each of these AbstractProducts.

The Client deals with AbstractFactory, AbstractProductA and AbstractProductB. It doesn't know anything about the implementations. The actual implementation of AbstractFactory that the Client uses is determined at runtime.

As you can see, one of the main benefits of this pattern is that the client is totally decoupled from the concrete products. Also, new product families can be easily added into the system, by just adding in a new type of ConcreteFactory that implements AbstractFactory, and creating the specific Product implementations.

== Facade Pattern Example ==

[[File:Facade-wo.JPG|300px|thumb|center|Without a Facade, the client has to deal with the intricacies of the sub system.]]

[[File:Facade-w.JPG|300px|thumb|center|With a Facade, the complexities of sub system are unified into a single interface making it readily usable for the client.]]

Considering the example for the Facade pattern, Client requires access to Employee objects, but in order to get that, it first need to contact the Database and retrieve the Company objects. It then retrieves Division objects from them and finally gains access to Employee objects. So, we see that It uses four classes and has to deal with complex details of the sub system. With Facade, the Client is shielded from most of the classes. It uses the Database Facade to retrieve Employee objects directly.

== Differences and similarities between Facade and Abstract Factory patterns ==
<ul>
<li>Facade is a structural design pattern whereas Abstract Factory pattern is a creational design pattern.
<li>Both are similar in a way that both provide an interface. Abstract Factory , provides kind of a Facade for creating products that belongs to its own factories.
<li>With the Abstract Factory Pattern we just provide a common factory builder for many different builders for the same thing. This can be used whenever we need to provide an interface to a set of builders meant to be used with something in common (the product) without bothering on what are we going to build or which factory are we going to use. The Facade pattern instead is used to provide a simple interface to a lot of different operations that the client classes should not see.
</ul>

Thus we see that both patterns achieve quite different goals. The facade pattern is used when you want to hide an implementation or it is about changing interface of some class or set of classes. On the other hand Abstarct factory pattern is used when you want to hide the details on constructing instances. Provide an interface for creating families of related or dependent objects without specifying their concrete classes.

=Mediator Pattern and Facade Pattern=
In Unix, permission to access system resources is managed at three levels of granularity: world, group, and owner. A group is a collection of users intended to model some functional affiliation. Each user on the system can be a member of one or more groups, and each group can have zero or more users assigned to it. Next figure shows three users that are assigned to all three groups. If we were to model this in software, we could decide to have User objects coupled to Group objects, and Group objects coupled to User objects. Then when changes occur, both classes and all their instances would be affected. An alternate approach would be to introduce “an additional level of indirection” - take the mapping of users to groups and groups to users, and make it an abstraction unto itself. This offers several advantages: Users and Groups are decoupled from one another, many mappings can easily be maintained and manipulated simultaneously, and the mapping abstraction can be extended in the future by defining derived classes. 

Partitioning a system into many objects generally enhances reusability, but proliferating interconnections between those objects tend to reduce it again. The mediator object: encapsulates all interconnections, acts as the hub of communication, is responsible for controlling and coordinating the interactions of its clients, and promotes loose coupling by keeping objects from referring to each other explicitly.

[[File:Mediator__1.gif]]

Colleagues (or peers) are not coupled to one another. Each talks to the Mediator, which in turn knows and conducts the orchestration of the others. The “many to many” mapping between colleagues that would otherwise exist, has been “promoted to full object status”. This new abstraction provides a locus of indirection where additional leverage can be hosted.

Mediator is similar to Facade in that it abstracts functionality of existing classes. Mediator abstracts/centralizes arbitrary communication between colleague objects, it routinely “adds value”, and it is known/referenced by the colleague objects (i.e. it defines a multidirectional protocol). In contrast, Facade defines a simpler interface to a subsystem, it doesn’t add new functionality, and it is not known by the subsystem classes (i.e. it defines a unidirectional protocol where it makes requests of the subsystem classes but not vice versa).

=References=
<references/>

== Additional Reading ==

* [http://java.dzone.com/articles/design-patterns-uncovered-1 Facade Pattern in Java] at java.dzone.com
* [http://www.cs.mcgill.ca/~hv/classes/CS400/01.hchen/doc/command/command.html Basics of Command Pattern]
* [http://www.dofactory.com/Patterns/PatternFacade.aspx Facade Pattern] at dofactory.com
* [http://www.dofactory.com/topic/1675/facade-with-factory-pattern.aspx Facade with Factory pattern] at dofactory.com
* [http://stackoverflow.com/questions/11188869/what-is-the-differences-between-facade-pattern-and-abstarct-factory-pattern.html difference between facade and abstract factory pattern] at stackoverflow.com
* [http://sourcemaking.com/design_patterns/command Behavorial Design Pattern - Command Pattern] at sourcemaking.com
* [http://www.coderanch.com/t/99780/patterns/Factory-Abstract-Factory-Pattern Facade
* [http://perfectjpattern.sourceforge.net/dp-command.html GoF Command Pattern]

* McDonald,J. 2008. Design Patterns

CSC/ECE 517 Fall 2012/ch2b 2w42 aa

2012-11-20T01:10:41Z

Aasawa: /* Additional Reading */

=Introduction =

==Facade Pattern==
Intent 
* Provide a unified interface to a set of interfaces in a subsystem. 
* Wrap a complicated subsystem with a simpler interface. 

Facade discusses encapsulating a complex subsystem within a single interface object. This reduces the learning curve necessary to successfully leverage the subsystem. It also promotes decoupling the subsystem from its potentially many clients. On the other hand, if the Facade is the only access point for the subsystem, it will limit the features and flexibility that “power users” may need. The Facade object should be a fairly simple advocate or facilitator. It should not become an all-knowing oracle or “god” object. 

== Adapter Pattern ==

Intent 
* Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn’t otherwise because of incompatible interfaces. 
* Wrap an existing class with a new interface. 
* Impedance match an old component to a new system. 

Convert the interface of a class into another interface clients expect. Adapter lets classes worktogether that couldn't otherwise because of incompatible interfaces.

==Abstract Factory Pattern==

Intent 
* Provide an interface for creating families of related or dependent objects without specifying their concrete classes. 
* A hierarchy that encapsulates: many possible “platforms”, and the construction of a suite of “products”. 
* The new operator considered harmful. 

If an application is to be portable, it needs to encapsulate platform dependencies. These “platforms” might include: windowing system, operating system, database, etc. Too often, this encapsulatation is not engineered in advance, and lots of #ifdef case statements with options for all currently supported platforms begin to procreate like rabbits throughout the code. 

==Mediator Pattern==
Intent 

* Define an object that encapsulates how a set of objects interact. Mediator promotes loose coupling by keeping objects from referring to each other explicitly, and it lets you vary their interaction independently.
* Design an intermediary to decouple many peers.
* Promote the many-to-many relationships between interacting peers to “full object status”.

=Facade Pattern =

==Non-Software examples<ref>[http://aspalliance.com/970_Facade_Design_Pattern.2 ASPAlliance - Facade Design Pattern - http://aspalliance.com/970_Facade_Design_Pattern.2]</ref>==
In most of the Pizza centers, orders will be given through phone calls with the customer interacting with the Customer service representative. In this case, consumers do not have access to the Billing system, Kitchen and delivery department. The customer service representative acts as an interface and interacts with each of the departments involved in the transaction and ensures that Pizzas are delivered to the consumer. Customer Service representative corresponds to the facade. Individual departments involved in the transaction correspond to Sub-systems.

==Software examples==
Web Service Facade Solution Architecture provides an example for Facade design pattern. In this architectural solution, instead of rewriting legacy applications or customizing those with middleware to connect to other applications one by one, this solution helps create a "facade" for the legacy application. Other applications are easily "plugged into" this facade. By modeling a legacy application into its basic functions of create, read, update, and delete and then exposing these functions as Web methods, the Web service facade solution allows other applications to access legacy data by making use of common Web services through standardized protocols. In this way, Facade decouples layers so that they do not depend on each other which can make it easier to develop, to use and to promote code re-use.

== C# Example ==
using System;
using System.Collections.Generic; 
namespace DesignPatterns.Facade
{
public class OrderFacade
{
//Places an Order and Returns an Order ID
public int placeOrder(int CustomerID, List<BasketItem> Products)
{
Order anOrder = new Order();
OrderLine anOrderLine = new OrderLine();
Address DespatchAddress = Address.getCustomerDespatchAddress(CustomerID);
int OrderId = anOrder.requestOrderID();
anOrder.createOrder(OrderId, DespatchAddress);
anOrderLine.addOrderLinesToOrder(OrderId, Products);
return OrderId;
}
} 
//order class
public class Order
{
public int requestOrderID()
{
//Creates and Returns a Unique Order ID
} 
public void createOrder(int OrderId, Address DespatchAddress)
{
}
} 
//OrderLine Class
public class OrderLine
{
public void addOrderLinesToOrder(int OrderId, List<BasketItem> Products)
{
}
} 
//Public Customer
public class Address
{
public static Address getCustomerDespatchAddress(int CustomerID)
{
return new Address();
}
//Address properties
} 
public class BasketItem
{
//BasketItem Properties
}
}

=Adapter Pattern and Facade Pattern =

Adapter functions as a wrapper or modifier of an existing class. It provides a different or translated view of that class. 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. Reuse has always been painful and elusive. One reason has been the tribulation of designing something new, while reusing something old. There is always something not quite right between the old and the new. It may be physical dimensions or misalignment. It may be timing or synchronization. It may be unfortunate assumptions or competing standards. It is like the problem of inserting a new three-prong electrical plug in an old two-prong wall outlet – some kind of adapter or intermediary is necessary. 

Adapter is about creating an intermediary abstraction that translates, or maps, the old component to the new system. Clients call methods on the Adapter object which redirects them into calls to the legacy component. This strategy can be implemented either with inheritance or with aggregation. 

== Adapter Pattern Example ==
<pre>
interface Shape {
void draw(...);
}

Class LegacyLine {
void draw(..) { }
}

Class LegacyRectangle {
void draw(..) { }
}

Class Line implements Shape {
adapter = new LegacyLine();
void draw(...) {adapter.draw(...)}
}

Class Rectangle implements Shape {
adapter = new LegacyRectangle();
void draw(...) {adapter.draw(...)}
}
</pre>

In the example provided for the Facade pattern, the method placeOrder() uses the methods exposed by many other classes such as Order, OrderLine, Address etc to provide a high level view for the callers. The callers need not worry about the complexities in handling the sub-system. The users of the Class OrderFacade just invoke the method placeOrder() with the necessary arguments and rest of the process is taken care by placeOrder(). As can be seen in this case, a new method (placeOrder) was defined which has the logic and the necessary steps to handle all the sub-systems to create an order, create an id for the order, create a dispatch address etc.

In the example provided for the Adapter pattern, no new methods are defined. The existing method draw of LegacyRectangle is wrapped in a adapter class Rectangle. The methods in adapter classes does the necessary manipulations to the arguments and then passes to the original classes.

On similar lines, assume that the implementation and structure of BasketItem in Facade example needs to be changed. To handle such scenario, a new adapter class BasketItemAdapter is defined. It implements all the methods of the BasketItem and in each method makes necessary changes to the arguments and passes it to the new implementation as shown below.
== Example ==
<pre>
public Class BasketItemAdapter {
BasketItem newImplementation = new BasketItem();
void calculateCost(...) {
//make necessary modification
newImplementation.calculateCost(...);
}
}
</pre>

== Differences and similarities ==
* In both the Facade and Adapter pattern we have pre-existing classes.
* In the Facade, however, we do not have an interface we must design to, as we do in the Adapter pattern.
* We are not interested in polymorphic behavior in the Facade, while in the Adapter, We probably am.(There are times when we just need to design to a particular API and therefore must use an Adapter)
* In the case of the Facade pattern, the motivation is to simplify the interface. With the Adapter, while simpler is better,We are trying to design to an existing interface and cannot simplify things even if a simpler interface were otherwise possible.

Bottom line is a Facade simplifies an interface while an Adapter converts the interface into a pre-existing interface.

=Abstract Factory Pattern and Facade Pattern =

Abstract factory pattern provides a level of indirection that abstracts the creation of families of related or dependent objects without directly specifying their concrete classes. The “factory” object has the responsibility for providing creation services for the entire platform family. Clients never create platform objects directly, they ask the factory to do that for them.

This mechanism makes exchanging product families easy because the specific class of the factory object appears only once in the application - where it is instantiated. The application can wholesale replace the entire family of products simply by instantiating a different concrete instance of the abstract factory. Because the service provided by the factory object is so pervasive, it is routinely implemented as a Singleton. 

== Abstract Factory Example ==
[[File:Abstract.JPG|600px|center]]

The AbstractFactory defines the interface that all of the concrete factories will need to implement in order to product Products. ConcreteFactoryA and ConcreteFactoryB have both implemented this interface here, creating two seperate families of product. Meanwhile, AbstractProductA and AbstractProductB are interfaces for the different types of product. Each factory will create one of each of these AbstractProducts.

The Client deals with AbstractFactory, AbstractProductA and AbstractProductB. It doesn't know anything about the implementations. The actual implementation of AbstractFactory that the Client uses is determined at runtime.

As you can see, one of the main benefits of this pattern is that the client is totally decoupled from the concrete products. Also, new product families can be easily added into the system, by just adding in a new type of ConcreteFactory that implements AbstractFactory, and creating the specific Product implementations.

== Facade Pattern Example ==

[[File:Facade-wo.JPG|300px|thumb|center|Without a Facade, the client has to deal with the intricacies of the sub system.]]

[[File:Facade-w.JPG|300px|thumb|center|With a Facade, the complexities of sub system are unified into a single interface making it readily usable for the client.]]

Considering the example for the Facade pattern, Client requires access to Employee objects, but in order to get that, it first need to contact the Database and retrieve the Company objects. It then retrieves Division objects from them and finally gains access to Employee objects. So, we see that It uses four classes and has to deal with complex details of the sub system. With Facade, the Client is shielded from most of the classes. It uses the Database Facade to retrieve Employee objects directly.

== Differences and similarities between Facade and Abstract Factory patterns ==
<ul>
<li>Facade is a structural design pattern whereas Abstract Factory pattern is a creational design pattern.
<li>Both are similar in a way that both provide an interface. Abstract Factory , provides kind of a Facade for creating products that belongs to its own factories.
<li>With the Abstract Factory Pattern we just provide a common factory builder for many different builders for the same thing. This can be used whenever we need to provide an interface to a set of builders meant to be used with something in common (the product) without bothering on what are we going to build or which factory are we going to use. The Facade pattern instead is used to provide a simple interface to a lot of different operations that the client classes should not see.
</ul>

Thus we see that both patterns achieve quite different goals. The facade pattern is used when you want to hide an implementation or it is about changing interface of some class or set of classes. On the other hand Abstarct factory pattern is used when you want to hide the details on constructing instances. Provide an interface for creating families of related or dependent objects without specifying their concrete classes.

=Mediator Pattern and Facade Pattern=
In Unix, permission to access system resources is managed at three levels of granularity: world, group, and owner. A group is a collection of users intended to model some functional affiliation. Each user on the system can be a member of one or more groups, and each group can have zero or more users assigned to it. Next figure shows three users that are assigned to all three groups. If we were to model this in software, we could decide to have User objects coupled to Group objects, and Group objects coupled to User objects. Then when changes occur, both classes and all their instances would be affected. An alternate approach would be to introduce “an additional level of indirection” - take the mapping of users to groups and groups to users, and make it an abstraction unto itself. This offers several advantages: Users and Groups are decoupled from one another, many mappings can easily be maintained and manipulated simultaneously, and the mapping abstraction can be extended in the future by defining derived classes. 

Partitioning a system into many objects generally enhances reusability, but proliferating interconnections between those objects tend to reduce it again. The mediator object: encapsulates all interconnections, acts as the hub of communication, is responsible for controlling and coordinating the interactions of its clients, and promotes loose coupling by keeping objects from referring to each other explicitly.

[[File:Mediator__1.gif]]

Colleagues (or peers) are not coupled to one another. Each talks to the Mediator, which in turn knows and conducts the orchestration of the others. The “many to many” mapping between colleagues that would otherwise exist, has been “promoted to full object status”. This new abstraction provides a locus of indirection where additional leverage can be hosted.

Mediator is similar to Facade in that it abstracts functionality of existing classes. Mediator abstracts/centralizes arbitrary communication between colleague objects, it routinely “adds value”, and it is known/referenced by the colleague objects (i.e. it defines a multidirectional protocol). In contrast, Facade defines a simpler interface to a subsystem, it doesn’t add new functionality, and it is not known by the subsystem classes (i.e. it defines a unidirectional protocol where it makes requests of the subsystem classes but not vice versa).

=References=
<references/>

== Additional Reading ==

* [http://java.dzone.com/articles/design-patterns-uncovered-1 Facade Pattern in Java] at java.dzone.com
* [http://www.cs.mcgill.ca/~hv/classes/CS400/01.hchen/doc/command/command.html Basics of Command Pattern]
* [http://www.dofactory.com/Patterns/PatternFacade.aspx Facade Pattern] at dofactory.com
* [http://www.dofactory.com/topic/1675/facade-with-factory-pattern.aspx Facade with Factory pattern] at dofactory.com
* [http://stackoverflow.com/questions/11188869/what-is-the-differences-between-facade-pattern-and-abstarct-factory-pattern.html difference between facade and abstract factory pattern] at stackoverflow.com
* [http://sourcemaking.com/design_patterns/command Behavorial Design Pattern - Command Pattern] at sourcemaking.com

* [http://perfectjpattern.sourceforge.net/dp-command.html GoF Command Pattern]

* McDonald,J. 2008. Design Patterns

CSC/ECE 517 Fall 2012/ch2b 2w42 aa

2012-11-20T01:09:14Z

Aasawa: /* Additional Reading */

=Introduction =

==Facade Pattern==
Intent 
* Provide a unified interface to a set of interfaces in a subsystem. 
* Wrap a complicated subsystem with a simpler interface. 

Facade discusses encapsulating a complex subsystem within a single interface object. This reduces the learning curve necessary to successfully leverage the subsystem. It also promotes decoupling the subsystem from its potentially many clients. On the other hand, if the Facade is the only access point for the subsystem, it will limit the features and flexibility that “power users” may need. The Facade object should be a fairly simple advocate or facilitator. It should not become an all-knowing oracle or “god” object. 

== Adapter Pattern ==

Intent 
* Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn’t otherwise because of incompatible interfaces. 
* Wrap an existing class with a new interface. 
* Impedance match an old component to a new system. 

Convert the interface of a class into another interface clients expect. Adapter lets classes worktogether that couldn't otherwise because of incompatible interfaces.

==Abstract Factory Pattern==

Intent 
* Provide an interface for creating families of related or dependent objects without specifying their concrete classes. 
* A hierarchy that encapsulates: many possible “platforms”, and the construction of a suite of “products”. 
* The new operator considered harmful. 

If an application is to be portable, it needs to encapsulate platform dependencies. These “platforms” might include: windowing system, operating system, database, etc. Too often, this encapsulatation is not engineered in advance, and lots of #ifdef case statements with options for all currently supported platforms begin to procreate like rabbits throughout the code. 

==Mediator Pattern==
Intent 

* Define an object that encapsulates how a set of objects interact. Mediator promotes loose coupling by keeping objects from referring to each other explicitly, and it lets you vary their interaction independently.
* Design an intermediary to decouple many peers.
* Promote the many-to-many relationships between interacting peers to “full object status”.

=Facade Pattern =

==Non-Software examples<ref>[http://aspalliance.com/970_Facade_Design_Pattern.2 ASPAlliance - Facade Design Pattern - http://aspalliance.com/970_Facade_Design_Pattern.2]</ref>==
In most of the Pizza centers, orders will be given through phone calls with the customer interacting with the Customer service representative. In this case, consumers do not have access to the Billing system, Kitchen and delivery department. The customer service representative acts as an interface and interacts with each of the departments involved in the transaction and ensures that Pizzas are delivered to the consumer. Customer Service representative corresponds to the facade. Individual departments involved in the transaction correspond to Sub-systems.

==Software examples==
Web Service Facade Solution Architecture provides an example for Facade design pattern. In this architectural solution, instead of rewriting legacy applications or customizing those with middleware to connect to other applications one by one, this solution helps create a "facade" for the legacy application. Other applications are easily "plugged into" this facade. By modeling a legacy application into its basic functions of create, read, update, and delete and then exposing these functions as Web methods, the Web service facade solution allows other applications to access legacy data by making use of common Web services through standardized protocols. In this way, Facade decouples layers so that they do not depend on each other which can make it easier to develop, to use and to promote code re-use.

== C# Example ==
using System;
using System.Collections.Generic; 
namespace DesignPatterns.Facade
{
public class OrderFacade
{
//Places an Order and Returns an Order ID
public int placeOrder(int CustomerID, List<BasketItem> Products)
{
Order anOrder = new Order();
OrderLine anOrderLine = new OrderLine();
Address DespatchAddress = Address.getCustomerDespatchAddress(CustomerID);
int OrderId = anOrder.requestOrderID();
anOrder.createOrder(OrderId, DespatchAddress);
anOrderLine.addOrderLinesToOrder(OrderId, Products);
return OrderId;
}
} 
//order class
public class Order
{
public int requestOrderID()
{
//Creates and Returns a Unique Order ID
} 
public void createOrder(int OrderId, Address DespatchAddress)
{
}
} 
//OrderLine Class
public class OrderLine
{
public void addOrderLinesToOrder(int OrderId, List<BasketItem> Products)
{
}
} 
//Public Customer
public class Address
{
public static Address getCustomerDespatchAddress(int CustomerID)
{
return new Address();
}
//Address properties
} 
public class BasketItem
{
//BasketItem Properties
}
}

=Adapter Pattern and Facade Pattern =

Adapter functions as a wrapper or modifier of an existing class. It provides a different or translated view of that class. 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. Reuse has always been painful and elusive. One reason has been the tribulation of designing something new, while reusing something old. There is always something not quite right between the old and the new. It may be physical dimensions or misalignment. It may be timing or synchronization. It may be unfortunate assumptions or competing standards. It is like the problem of inserting a new three-prong electrical plug in an old two-prong wall outlet – some kind of adapter or intermediary is necessary. 

Adapter is about creating an intermediary abstraction that translates, or maps, the old component to the new system. Clients call methods on the Adapter object which redirects them into calls to the legacy component. This strategy can be implemented either with inheritance or with aggregation. 

== Adapter Pattern Example ==
<pre>
interface Shape {
void draw(...);
}

Class LegacyLine {
void draw(..) { }
}

Class LegacyRectangle {
void draw(..) { }
}

Class Line implements Shape {
adapter = new LegacyLine();
void draw(...) {adapter.draw(...)}
}

Class Rectangle implements Shape {
adapter = new LegacyRectangle();
void draw(...) {adapter.draw(...)}
}
</pre>

In the example provided for the Facade pattern, the method placeOrder() uses the methods exposed by many other classes such as Order, OrderLine, Address etc to provide a high level view for the callers. The callers need not worry about the complexities in handling the sub-system. The users of the Class OrderFacade just invoke the method placeOrder() with the necessary arguments and rest of the process is taken care by placeOrder(). As can be seen in this case, a new method (placeOrder) was defined which has the logic and the necessary steps to handle all the sub-systems to create an order, create an id for the order, create a dispatch address etc.

In the example provided for the Adapter pattern, no new methods are defined. The existing method draw of LegacyRectangle is wrapped in a adapter class Rectangle. The methods in adapter classes does the necessary manipulations to the arguments and then passes to the original classes.

On similar lines, assume that the implementation and structure of BasketItem in Facade example needs to be changed. To handle such scenario, a new adapter class BasketItemAdapter is defined. It implements all the methods of the BasketItem and in each method makes necessary changes to the arguments and passes it to the new implementation as shown below.
== Example ==
<pre>
public Class BasketItemAdapter {
BasketItem newImplementation = new BasketItem();
void calculateCost(...) {
//make necessary modification
newImplementation.calculateCost(...);
}
}
</pre>

== Differences and similarities ==
* In both the Facade and Adapter pattern we have pre-existing classes.
* In the Facade, however, we do not have an interface we must design to, as we do in the Adapter pattern.
* We are not interested in polymorphic behavior in the Facade, while in the Adapter, We probably am.(There are times when we just need to design to a particular API and therefore must use an Adapter)
* In the case of the Facade pattern, the motivation is to simplify the interface. With the Adapter, while simpler is better,We are trying to design to an existing interface and cannot simplify things even if a simpler interface were otherwise possible.

Bottom line is a Facade simplifies an interface while an Adapter converts the interface into a pre-existing interface.

=Abstract Factory Pattern and Facade Pattern =

Abstract factory pattern provides a level of indirection that abstracts the creation of families of related or dependent objects without directly specifying their concrete classes. The “factory” object has the responsibility for providing creation services for the entire platform family. Clients never create platform objects directly, they ask the factory to do that for them.

This mechanism makes exchanging product families easy because the specific class of the factory object appears only once in the application - where it is instantiated. The application can wholesale replace the entire family of products simply by instantiating a different concrete instance of the abstract factory. Because the service provided by the factory object is so pervasive, it is routinely implemented as a Singleton. 

== Abstract Factory Example ==
[[File:Abstract.JPG|600px|center]]

The AbstractFactory defines the interface that all of the concrete factories will need to implement in order to product Products. ConcreteFactoryA and ConcreteFactoryB have both implemented this interface here, creating two seperate families of product. Meanwhile, AbstractProductA and AbstractProductB are interfaces for the different types of product. Each factory will create one of each of these AbstractProducts.

The Client deals with AbstractFactory, AbstractProductA and AbstractProductB. It doesn't know anything about the implementations. The actual implementation of AbstractFactory that the Client uses is determined at runtime.

As you can see, one of the main benefits of this pattern is that the client is totally decoupled from the concrete products. Also, new product families can be easily added into the system, by just adding in a new type of ConcreteFactory that implements AbstractFactory, and creating the specific Product implementations.

== Facade Pattern Example ==

[[File:Facade-wo.JPG|300px|thumb|center|Without a Facade, the client has to deal with the intricacies of the sub system.]]

[[File:Facade-w.JPG|300px|thumb|center|With a Facade, the complexities of sub system are unified into a single interface making it readily usable for the client.]]

Considering the example for the Facade pattern, Client requires access to Employee objects, but in order to get that, it first need to contact the Database and retrieve the Company objects. It then retrieves Division objects from them and finally gains access to Employee objects. So, we see that It uses four classes and has to deal with complex details of the sub system. With Facade, the Client is shielded from most of the classes. It uses the Database Facade to retrieve Employee objects directly.

== Differences and similarities between Facade and Abstract Factory patterns ==
<ul>
<li>Facade is a structural design pattern whereas Abstract Factory pattern is a creational design pattern.
<li>Both are similar in a way that both provide an interface. Abstract Factory , provides kind of a Facade for creating products that belongs to its own factories.
<li>With the Abstract Factory Pattern we just provide a common factory builder for many different builders for the same thing. This can be used whenever we need to provide an interface to a set of builders meant to be used with something in common (the product) without bothering on what are we going to build or which factory are we going to use. The Facade pattern instead is used to provide a simple interface to a lot of different operations that the client classes should not see.
</ul>

Thus we see that both patterns achieve quite different goals. The facade pattern is used when you want to hide an implementation or it is about changing interface of some class or set of classes. On the other hand Abstarct factory pattern is used when you want to hide the details on constructing instances. Provide an interface for creating families of related or dependent objects without specifying their concrete classes.

=Mediator Pattern and Facade Pattern=
In Unix, permission to access system resources is managed at three levels of granularity: world, group, and owner. A group is a collection of users intended to model some functional affiliation. Each user on the system can be a member of one or more groups, and each group can have zero or more users assigned to it. Next figure shows three users that are assigned to all three groups. If we were to model this in software, we could decide to have User objects coupled to Group objects, and Group objects coupled to User objects. Then when changes occur, both classes and all their instances would be affected. An alternate approach would be to introduce “an additional level of indirection” - take the mapping of users to groups and groups to users, and make it an abstraction unto itself. This offers several advantages: Users and Groups are decoupled from one another, many mappings can easily be maintained and manipulated simultaneously, and the mapping abstraction can be extended in the future by defining derived classes. 

Partitioning a system into many objects generally enhances reusability, but proliferating interconnections between those objects tend to reduce it again. The mediator object: encapsulates all interconnections, acts as the hub of communication, is responsible for controlling and coordinating the interactions of its clients, and promotes loose coupling by keeping objects from referring to each other explicitly.

[[File:Mediator__1.gif]]

Colleagues (or peers) are not coupled to one another. Each talks to the Mediator, which in turn knows and conducts the orchestration of the others. The “many to many” mapping between colleagues that would otherwise exist, has been “promoted to full object status”. This new abstraction provides a locus of indirection where additional leverage can be hosted.

Mediator is similar to Facade in that it abstracts functionality of existing classes. Mediator abstracts/centralizes arbitrary communication between colleague objects, it routinely “adds value”, and it is known/referenced by the colleague objects (i.e. it defines a multidirectional protocol). In contrast, Facade defines a simpler interface to a subsystem, it doesn’t add new functionality, and it is not known by the subsystem classes (i.e. it defines a unidirectional protocol where it makes requests of the subsystem classes but not vice versa).

=References=
<references/>

== Additional Reading ==

* [http://java.dzone.com/articles/design-patterns-command Command Pattern in Java] at java.dzone.com
* [http://www.cs.mcgill.ca/~hv/classes/CS400/01.hchen/doc/command/command.html Basics of Command Pattern]
* [http://www.dofactory.com/Patterns/PatternFacade.aspx Facade Pattern] at dofactory.com
* [http://www.dofactory.com/topic/1675/facade-with-factory-pattern.aspx Facade with Factory pattern] at dofactory.com
* [http://stackoverflow.com/questions/11188869/what-is-the-differences-between-facade-pattern-and-abstarct-factory-pattern
difference between facade and abstract factory pattern] at stackoverflow.com
* [http://sourcemaking.com/design_patterns/command Behavorial Design Pattern - Command Pattern] at sourcemaking.com

* [http://perfectjpattern.sourceforge.net/dp-command.html GoF Command Pattern]

* McDonald,J. 2008. Design Patterns

CSC/ECE 517 Fall 2012/ch2b 2w42 aa

2012-11-20T01:06:49Z

Aasawa: /* Additional Reading */

=Introduction =

==Facade Pattern==
Intent 
* Provide a unified interface to a set of interfaces in a subsystem. 
* Wrap a complicated subsystem with a simpler interface. 

Facade discusses encapsulating a complex subsystem within a single interface object. This reduces the learning curve necessary to successfully leverage the subsystem. It also promotes decoupling the subsystem from its potentially many clients. On the other hand, if the Facade is the only access point for the subsystem, it will limit the features and flexibility that “power users” may need. The Facade object should be a fairly simple advocate or facilitator. It should not become an all-knowing oracle or “god” object. 

== Adapter Pattern ==

Intent 
* Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn’t otherwise because of incompatible interfaces. 
* Wrap an existing class with a new interface. 
* Impedance match an old component to a new system. 

Convert the interface of a class into another interface clients expect. Adapter lets classes worktogether that couldn't otherwise because of incompatible interfaces.

==Abstract Factory Pattern==

Intent 
* Provide an interface for creating families of related or dependent objects without specifying their concrete classes. 
* A hierarchy that encapsulates: many possible “platforms”, and the construction of a suite of “products”. 
* The new operator considered harmful. 

If an application is to be portable, it needs to encapsulate platform dependencies. These “platforms” might include: windowing system, operating system, database, etc. Too often, this encapsulatation is not engineered in advance, and lots of #ifdef case statements with options for all currently supported platforms begin to procreate like rabbits throughout the code. 

==Mediator Pattern==
Intent 

* Define an object that encapsulates how a set of objects interact. Mediator promotes loose coupling by keeping objects from referring to each other explicitly, and it lets you vary their interaction independently.
* Design an intermediary to decouple many peers.
* Promote the many-to-many relationships between interacting peers to “full object status”.

=Facade Pattern =

==Non-Software examples<ref>[http://aspalliance.com/970_Facade_Design_Pattern.2 ASPAlliance - Facade Design Pattern - http://aspalliance.com/970_Facade_Design_Pattern.2]</ref>==
In most of the Pizza centers, orders will be given through phone calls with the customer interacting with the Customer service representative. In this case, consumers do not have access to the Billing system, Kitchen and delivery department. The customer service representative acts as an interface and interacts with each of the departments involved in the transaction and ensures that Pizzas are delivered to the consumer. Customer Service representative corresponds to the facade. Individual departments involved in the transaction correspond to Sub-systems.

==Software examples==
Web Service Facade Solution Architecture provides an example for Facade design pattern. In this architectural solution, instead of rewriting legacy applications or customizing those with middleware to connect to other applications one by one, this solution helps create a "facade" for the legacy application. Other applications are easily "plugged into" this facade. By modeling a legacy application into its basic functions of create, read, update, and delete and then exposing these functions as Web methods, the Web service facade solution allows other applications to access legacy data by making use of common Web services through standardized protocols. In this way, Facade decouples layers so that they do not depend on each other which can make it easier to develop, to use and to promote code re-use.

== C# Example ==
using System;
using System.Collections.Generic; 
namespace DesignPatterns.Facade
{
public class OrderFacade
{
//Places an Order and Returns an Order ID
public int placeOrder(int CustomerID, List<BasketItem> Products)
{
Order anOrder = new Order();
OrderLine anOrderLine = new OrderLine();
Address DespatchAddress = Address.getCustomerDespatchAddress(CustomerID);
int OrderId = anOrder.requestOrderID();
anOrder.createOrder(OrderId, DespatchAddress);
anOrderLine.addOrderLinesToOrder(OrderId, Products);
return OrderId;
}
} 
//order class
public class Order
{
public int requestOrderID()
{
//Creates and Returns a Unique Order ID
} 
public void createOrder(int OrderId, Address DespatchAddress)
{
}
} 
//OrderLine Class
public class OrderLine
{
public void addOrderLinesToOrder(int OrderId, List<BasketItem> Products)
{
}
} 
//Public Customer
public class Address
{
public static Address getCustomerDespatchAddress(int CustomerID)
{
return new Address();
}
//Address properties
} 
public class BasketItem
{
//BasketItem Properties
}
}

=Adapter Pattern and Facade Pattern =

Adapter functions as a wrapper or modifier of an existing class. It provides a different or translated view of that class. 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. Reuse has always been painful and elusive. One reason has been the tribulation of designing something new, while reusing something old. There is always something not quite right between the old and the new. It may be physical dimensions or misalignment. It may be timing or synchronization. It may be unfortunate assumptions or competing standards. It is like the problem of inserting a new three-prong electrical plug in an old two-prong wall outlet – some kind of adapter or intermediary is necessary. 

Adapter is about creating an intermediary abstraction that translates, or maps, the old component to the new system. Clients call methods on the Adapter object which redirects them into calls to the legacy component. This strategy can be implemented either with inheritance or with aggregation. 

== Adapter Pattern Example ==
<pre>
interface Shape {
void draw(...);
}

Class LegacyLine {
void draw(..) { }
}

Class LegacyRectangle {
void draw(..) { }
}

Class Line implements Shape {
adapter = new LegacyLine();
void draw(...) {adapter.draw(...)}
}

Class Rectangle implements Shape {
adapter = new LegacyRectangle();
void draw(...) {adapter.draw(...)}
}
</pre>

In the example provided for the Facade pattern, the method placeOrder() uses the methods exposed by many other classes such as Order, OrderLine, Address etc to provide a high level view for the callers. The callers need not worry about the complexities in handling the sub-system. The users of the Class OrderFacade just invoke the method placeOrder() with the necessary arguments and rest of the process is taken care by placeOrder(). As can be seen in this case, a new method (placeOrder) was defined which has the logic and the necessary steps to handle all the sub-systems to create an order, create an id for the order, create a dispatch address etc.

In the example provided for the Adapter pattern, no new methods are defined. The existing method draw of LegacyRectangle is wrapped in a adapter class Rectangle. The methods in adapter classes does the necessary manipulations to the arguments and then passes to the original classes.

On similar lines, assume that the implementation and structure of BasketItem in Facade example needs to be changed. To handle such scenario, a new adapter class BasketItemAdapter is defined. It implements all the methods of the BasketItem and in each method makes necessary changes to the arguments and passes it to the new implementation as shown below.
== Example ==
<pre>
public Class BasketItemAdapter {
BasketItem newImplementation = new BasketItem();
void calculateCost(...) {
//make necessary modification
newImplementation.calculateCost(...);
}
}
</pre>

== Differences and similarities ==
* In both the Facade and Adapter pattern we have pre-existing classes.
* In the Facade, however, we do not have an interface we must design to, as we do in the Adapter pattern.
* We are not interested in polymorphic behavior in the Facade, while in the Adapter, We probably am.(There are times when we just need to design to a particular API and therefore must use an Adapter)
* In the case of the Facade pattern, the motivation is to simplify the interface. With the Adapter, while simpler is better,We are trying to design to an existing interface and cannot simplify things even if a simpler interface were otherwise possible.

Bottom line is a Facade simplifies an interface while an Adapter converts the interface into a pre-existing interface.

=Abstract Factory Pattern and Facade Pattern =

Abstract factory pattern provides a level of indirection that abstracts the creation of families of related or dependent objects without directly specifying their concrete classes. The “factory” object has the responsibility for providing creation services for the entire platform family. Clients never create platform objects directly, they ask the factory to do that for them.

This mechanism makes exchanging product families easy because the specific class of the factory object appears only once in the application - where it is instantiated. The application can wholesale replace the entire family of products simply by instantiating a different concrete instance of the abstract factory. Because the service provided by the factory object is so pervasive, it is routinely implemented as a Singleton. 

== Abstract Factory Example ==
[[File:Abstract.JPG|600px|center]]

The AbstractFactory defines the interface that all of the concrete factories will need to implement in order to product Products. ConcreteFactoryA and ConcreteFactoryB have both implemented this interface here, creating two seperate families of product. Meanwhile, AbstractProductA and AbstractProductB are interfaces for the different types of product. Each factory will create one of each of these AbstractProducts.

The Client deals with AbstractFactory, AbstractProductA and AbstractProductB. It doesn't know anything about the implementations. The actual implementation of AbstractFactory that the Client uses is determined at runtime.

As you can see, one of the main benefits of this pattern is that the client is totally decoupled from the concrete products. Also, new product families can be easily added into the system, by just adding in a new type of ConcreteFactory that implements AbstractFactory, and creating the specific Product implementations.

== Facade Pattern Example ==

[[File:Facade-wo.JPG|300px|thumb|center|Without a Facade, the client has to deal with the intricacies of the sub system.]]

[[File:Facade-w.JPG|300px|thumb|center|With a Facade, the complexities of sub system are unified into a single interface making it readily usable for the client.]]

Considering the example for the Facade pattern, Client requires access to Employee objects, but in order to get that, it first need to contact the Database and retrieve the Company objects. It then retrieves Division objects from them and finally gains access to Employee objects. So, we see that It uses four classes and has to deal with complex details of the sub system. With Facade, the Client is shielded from most of the classes. It uses the Database Facade to retrieve Employee objects directly.

== Differences and similarities between Facade and Abstract Factory patterns ==
<ul>
<li>Facade is a structural design pattern whereas Abstract Factory pattern is a creational design pattern.
<li>Both are similar in a way that both provide an interface. Abstract Factory , provides kind of a Facade for creating products that belongs to its own factories.
<li>With the Abstract Factory Pattern we just provide a common factory builder for many different builders for the same thing. This can be used whenever we need to provide an interface to a set of builders meant to be used with something in common (the product) without bothering on what are we going to build or which factory are we going to use. The Facade pattern instead is used to provide a simple interface to a lot of different operations that the client classes should not see.
</ul>

Thus we see that both patterns achieve quite different goals. The facade pattern is used when you want to hide an implementation or it is about changing interface of some class or set of classes. On the other hand Abstarct factory pattern is used when you want to hide the details on constructing instances. Provide an interface for creating families of related or dependent objects without specifying their concrete classes.

=Mediator Pattern and Facade Pattern=
In Unix, permission to access system resources is managed at three levels of granularity: world, group, and owner. A group is a collection of users intended to model some functional affiliation. Each user on the system can be a member of one or more groups, and each group can have zero or more users assigned to it. Next figure shows three users that are assigned to all three groups. If we were to model this in software, we could decide to have User objects coupled to Group objects, and Group objects coupled to User objects. Then when changes occur, both classes and all their instances would be affected. An alternate approach would be to introduce “an additional level of indirection” - take the mapping of users to groups and groups to users, and make it an abstraction unto itself. This offers several advantages: Users and Groups are decoupled from one another, many mappings can easily be maintained and manipulated simultaneously, and the mapping abstraction can be extended in the future by defining derived classes. 

Partitioning a system into many objects generally enhances reusability, but proliferating interconnections between those objects tend to reduce it again. The mediator object: encapsulates all interconnections, acts as the hub of communication, is responsible for controlling and coordinating the interactions of its clients, and promotes loose coupling by keeping objects from referring to each other explicitly.

[[File:Mediator__1.gif]]

Colleagues (or peers) are not coupled to one another. Each talks to the Mediator, which in turn knows and conducts the orchestration of the others. The “many to many” mapping between colleagues that would otherwise exist, has been “promoted to full object status”. This new abstraction provides a locus of indirection where additional leverage can be hosted.

Mediator is similar to Facade in that it abstracts functionality of existing classes. Mediator abstracts/centralizes arbitrary communication between colleague objects, it routinely “adds value”, and it is known/referenced by the colleague objects (i.e. it defines a multidirectional protocol). In contrast, Facade defines a simpler interface to a subsystem, it doesn’t add new functionality, and it is not known by the subsystem classes (i.e. it defines a unidirectional protocol where it makes requests of the subsystem classes but not vice versa).

=References=
<references/>

== Additional Reading ==

* [http://www.codeproject.com/Articles/15207/Design-Patterns-Command-Pattern Design Pattern: Command Pattern] at codeproject.com
* [http://java.dzone.com/articles/design-patterns-command Command Pattern in Java] at java.dzone.com
* [http://www.cs.mcgill.ca/~hv/classes/CS400/01.hchen/doc/command/command.html Basics of Command Pattern]
* [http://www.dofactory.com/Patterns/PatternFacade.aspx Facade Pattern] at dofactory.com
* [http://www.dofactory.com/topic/1675/facade-with-factory-pattern.aspx Facade with Factory pattern] at dofactory.com

* [http://sourcemaking.com/design_patterns/command Behavorial Design Pattern - Command Pattern] at sourcemaking.com

* [http://perfectjpattern.sourceforge.net/dp-command.html GoF Command Pattern]

* McDonald,J. 2008. Design Patterns

CSC/ECE 517 Fall 2012/ch2b 2w42 aa

2012-11-20T01:06:02Z

Aasawa: /* Additional Reading */

=Introduction =

==Facade Pattern==
Intent 
* Provide a unified interface to a set of interfaces in a subsystem. 
* Wrap a complicated subsystem with a simpler interface. 

Facade discusses encapsulating a complex subsystem within a single interface object. This reduces the learning curve necessary to successfully leverage the subsystem. It also promotes decoupling the subsystem from its potentially many clients. On the other hand, if the Facade is the only access point for the subsystem, it will limit the features and flexibility that “power users” may need. The Facade object should be a fairly simple advocate or facilitator. It should not become an all-knowing oracle or “god” object. 

== Adapter Pattern ==

Intent 
* Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn’t otherwise because of incompatible interfaces. 
* Wrap an existing class with a new interface. 
* Impedance match an old component to a new system. 

Convert the interface of a class into another interface clients expect. Adapter lets classes worktogether that couldn't otherwise because of incompatible interfaces.

==Abstract Factory Pattern==

Intent 
* Provide an interface for creating families of related or dependent objects without specifying their concrete classes. 
* A hierarchy that encapsulates: many possible “platforms”, and the construction of a suite of “products”. 
* The new operator considered harmful. 

If an application is to be portable, it needs to encapsulate platform dependencies. These “platforms” might include: windowing system, operating system, database, etc. Too often, this encapsulatation is not engineered in advance, and lots of #ifdef case statements with options for all currently supported platforms begin to procreate like rabbits throughout the code. 

==Mediator Pattern==
Intent 

* Define an object that encapsulates how a set of objects interact. Mediator promotes loose coupling by keeping objects from referring to each other explicitly, and it lets you vary their interaction independently.
* Design an intermediary to decouple many peers.
* Promote the many-to-many relationships between interacting peers to “full object status”.

=Facade Pattern =

==Non-Software examples<ref>[http://aspalliance.com/970_Facade_Design_Pattern.2 ASPAlliance - Facade Design Pattern - http://aspalliance.com/970_Facade_Design_Pattern.2]</ref>==
In most of the Pizza centers, orders will be given through phone calls with the customer interacting with the Customer service representative. In this case, consumers do not have access to the Billing system, Kitchen and delivery department. The customer service representative acts as an interface and interacts with each of the departments involved in the transaction and ensures that Pizzas are delivered to the consumer. Customer Service representative corresponds to the facade. Individual departments involved in the transaction correspond to Sub-systems.

==Software examples==
Web Service Facade Solution Architecture provides an example for Facade design pattern. In this architectural solution, instead of rewriting legacy applications or customizing those with middleware to connect to other applications one by one, this solution helps create a "facade" for the legacy application. Other applications are easily "plugged into" this facade. By modeling a legacy application into its basic functions of create, read, update, and delete and then exposing these functions as Web methods, the Web service facade solution allows other applications to access legacy data by making use of common Web services through standardized protocols. In this way, Facade decouples layers so that they do not depend on each other which can make it easier to develop, to use and to promote code re-use.

== C# Example ==
using System;
using System.Collections.Generic; 
namespace DesignPatterns.Facade
{
public class OrderFacade
{
//Places an Order and Returns an Order ID
public int placeOrder(int CustomerID, List<BasketItem> Products)
{
Order anOrder = new Order();
OrderLine anOrderLine = new OrderLine();
Address DespatchAddress = Address.getCustomerDespatchAddress(CustomerID);
int OrderId = anOrder.requestOrderID();
anOrder.createOrder(OrderId, DespatchAddress);
anOrderLine.addOrderLinesToOrder(OrderId, Products);
return OrderId;
}
} 
//order class
public class Order
{
public int requestOrderID()
{
//Creates and Returns a Unique Order ID
} 
public void createOrder(int OrderId, Address DespatchAddress)
{
}
} 
//OrderLine Class
public class OrderLine
{
public void addOrderLinesToOrder(int OrderId, List<BasketItem> Products)
{
}
} 
//Public Customer
public class Address
{
public static Address getCustomerDespatchAddress(int CustomerID)
{
return new Address();
}
//Address properties
} 
public class BasketItem
{
//BasketItem Properties
}
}

=Adapter Pattern and Facade Pattern =

Adapter functions as a wrapper or modifier of an existing class. It provides a different or translated view of that class. 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. Reuse has always been painful and elusive. One reason has been the tribulation of designing something new, while reusing something old. There is always something not quite right between the old and the new. It may be physical dimensions or misalignment. It may be timing or synchronization. It may be unfortunate assumptions or competing standards. It is like the problem of inserting a new three-prong electrical plug in an old two-prong wall outlet – some kind of adapter or intermediary is necessary. 

Adapter is about creating an intermediary abstraction that translates, or maps, the old component to the new system. Clients call methods on the Adapter object which redirects them into calls to the legacy component. This strategy can be implemented either with inheritance or with aggregation. 

== Adapter Pattern Example ==
<pre>
interface Shape {
void draw(...);
}

Class LegacyLine {
void draw(..) { }
}

Class LegacyRectangle {
void draw(..) { }
}

Class Line implements Shape {
adapter = new LegacyLine();
void draw(...) {adapter.draw(...)}
}

Class Rectangle implements Shape {
adapter = new LegacyRectangle();
void draw(...) {adapter.draw(...)}
}
</pre>

In the example provided for the Facade pattern, the method placeOrder() uses the methods exposed by many other classes such as Order, OrderLine, Address etc to provide a high level view for the callers. The callers need not worry about the complexities in handling the sub-system. The users of the Class OrderFacade just invoke the method placeOrder() with the necessary arguments and rest of the process is taken care by placeOrder(). As can be seen in this case, a new method (placeOrder) was defined which has the logic and the necessary steps to handle all the sub-systems to create an order, create an id for the order, create a dispatch address etc.

In the example provided for the Adapter pattern, no new methods are defined. The existing method draw of LegacyRectangle is wrapped in a adapter class Rectangle. The methods in adapter classes does the necessary manipulations to the arguments and then passes to the original classes.

On similar lines, assume that the implementation and structure of BasketItem in Facade example needs to be changed. To handle such scenario, a new adapter class BasketItemAdapter is defined. It implements all the methods of the BasketItem and in each method makes necessary changes to the arguments and passes it to the new implementation as shown below.
== Example ==
<pre>
public Class BasketItemAdapter {
BasketItem newImplementation = new BasketItem();
void calculateCost(...) {
//make necessary modification
newImplementation.calculateCost(...);
}
}
</pre>

== Differences and similarities ==
* In both the Facade and Adapter pattern we have pre-existing classes.
* In the Facade, however, we do not have an interface we must design to, as we do in the Adapter pattern.
* We are not interested in polymorphic behavior in the Facade, while in the Adapter, We probably am.(There are times when we just need to design to a particular API and therefore must use an Adapter)
* In the case of the Facade pattern, the motivation is to simplify the interface. With the Adapter, while simpler is better,We are trying to design to an existing interface and cannot simplify things even if a simpler interface were otherwise possible.

Bottom line is a Facade simplifies an interface while an Adapter converts the interface into a pre-existing interface.

=Abstract Factory Pattern and Facade Pattern =

Abstract factory pattern provides a level of indirection that abstracts the creation of families of related or dependent objects without directly specifying their concrete classes. The “factory” object has the responsibility for providing creation services for the entire platform family. Clients never create platform objects directly, they ask the factory to do that for them.

This mechanism makes exchanging product families easy because the specific class of the factory object appears only once in the application - where it is instantiated. The application can wholesale replace the entire family of products simply by instantiating a different concrete instance of the abstract factory. Because the service provided by the factory object is so pervasive, it is routinely implemented as a Singleton. 

== Abstract Factory Example ==
[[File:Abstract.JPG|600px|center]]

The AbstractFactory defines the interface that all of the concrete factories will need to implement in order to product Products. ConcreteFactoryA and ConcreteFactoryB have both implemented this interface here, creating two seperate families of product. Meanwhile, AbstractProductA and AbstractProductB are interfaces for the different types of product. Each factory will create one of each of these AbstractProducts.

The Client deals with AbstractFactory, AbstractProductA and AbstractProductB. It doesn't know anything about the implementations. The actual implementation of AbstractFactory that the Client uses is determined at runtime.

As you can see, one of the main benefits of this pattern is that the client is totally decoupled from the concrete products. Also, new product families can be easily added into the system, by just adding in a new type of ConcreteFactory that implements AbstractFactory, and creating the specific Product implementations.

== Facade Pattern Example ==

[[File:Facade-wo.JPG|300px|thumb|center|Without a Facade, the client has to deal with the intricacies of the sub system.]]

[[File:Facade-w.JPG|300px|thumb|center|With a Facade, the complexities of sub system are unified into a single interface making it readily usable for the client.]]

Considering the example for the Facade pattern, Client requires access to Employee objects, but in order to get that, it first need to contact the Database and retrieve the Company objects. It then retrieves Division objects from them and finally gains access to Employee objects. So, we see that It uses four classes and has to deal with complex details of the sub system. With Facade, the Client is shielded from most of the classes. It uses the Database Facade to retrieve Employee objects directly.

== Differences and similarities between Facade and Abstract Factory patterns ==
<ul>
<li>Facade is a structural design pattern whereas Abstract Factory pattern is a creational design pattern.
<li>Both are similar in a way that both provide an interface. Abstract Factory , provides kind of a Facade for creating products that belongs to its own factories.
<li>With the Abstract Factory Pattern we just provide a common factory builder for many different builders for the same thing. This can be used whenever we need to provide an interface to a set of builders meant to be used with something in common (the product) without bothering on what are we going to build or which factory are we going to use. The Facade pattern instead is used to provide a simple interface to a lot of different operations that the client classes should not see.
</ul>

Thus we see that both patterns achieve quite different goals. The facade pattern is used when you want to hide an implementation or it is about changing interface of some class or set of classes. On the other hand Abstarct factory pattern is used when you want to hide the details on constructing instances. Provide an interface for creating families of related or dependent objects without specifying their concrete classes.

=Mediator Pattern and Facade Pattern=
In Unix, permission to access system resources is managed at three levels of granularity: world, group, and owner. A group is a collection of users intended to model some functional affiliation. Each user on the system can be a member of one or more groups, and each group can have zero or more users assigned to it. Next figure shows three users that are assigned to all three groups. If we were to model this in software, we could decide to have User objects coupled to Group objects, and Group objects coupled to User objects. Then when changes occur, both classes and all their instances would be affected. An alternate approach would be to introduce “an additional level of indirection” - take the mapping of users to groups and groups to users, and make it an abstraction unto itself. This offers several advantages: Users and Groups are decoupled from one another, many mappings can easily be maintained and manipulated simultaneously, and the mapping abstraction can be extended in the future by defining derived classes. 

Partitioning a system into many objects generally enhances reusability, but proliferating interconnections between those objects tend to reduce it again. The mediator object: encapsulates all interconnections, acts as the hub of communication, is responsible for controlling and coordinating the interactions of its clients, and promotes loose coupling by keeping objects from referring to each other explicitly.

[[File:Mediator__1.gif]]

Colleagues (or peers) are not coupled to one another. Each talks to the Mediator, which in turn knows and conducts the orchestration of the others. The “many to many” mapping between colleagues that would otherwise exist, has been “promoted to full object status”. This new abstraction provides a locus of indirection where additional leverage can be hosted.

Mediator is similar to Facade in that it abstracts functionality of existing classes. Mediator abstracts/centralizes arbitrary communication between colleague objects, it routinely “adds value”, and it is known/referenced by the colleague objects (i.e. it defines a multidirectional protocol). In contrast, Facade defines a simpler interface to a subsystem, it doesn’t add new functionality, and it is not known by the subsystem classes (i.e. it defines a unidirectional protocol where it makes requests of the subsystem classes but not vice versa).

=References=
<references/>

== Additional Reading ==

* [http://www.codeproject.com/Articles/15207/Design-Patterns-Command-Pattern Design Pattern: Command Pattern] at codeproject.com
* [http://java.dzone.com/articles/design-patterns-command Command Pattern in Java] at java.dzone.com
* [http://www.cs.mcgill.ca/~hv/classes/CS400/01.hchen/doc/command/command.html Basics of Command Pattern]
* [http://www.dofactory.com/topic/1675/facade-with-factory-pattern.aspx Facade with Factory pattern] at dofactory.com

* [http://sourcemaking.com/design_patterns/command Behavorial Design Pattern - Command Pattern] at sourcemaking.com

* [http://perfectjpattern.sourceforge.net/dp-command.html GoF Command Pattern]

* McDonald,J. 2008. Design Patterns

CSC/ECE 517 Fall 2012/ch1b 1w52 an

2012-11-20T01:04:50Z

Aasawa: Undo revision 70983 by Aasawa (talk)

== '''Command Pattern ''' ==

Command Pattern is a [http://en.wikipedia.org/wiki/Design_pattern_(computer_science) design pattern] in [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming] in which an object is used to represent and [http://en.wikipedia.org/wiki/Encapsulation_(computer_science)#Encapsulation encapsulate] all the information needed to call a method at a later time. This information comprises of, the method name, the object that is the owner of the method and values for the method parameters. It encapsulates a request as an object and gives it a known public interface. It ensures that every object receives its own commands and provides a [http://en.wikipedia.org/wiki/Decoupling#Software_Development decoupling] between sender and receiver. In this case a sender is an object that invokes an operation, and a receiver is an object that receives the request and acts on it.

There are three main components of a Command pattern: the ''Invoker'', the ''Command'', and the ''Receiver''. The invoker component acts as a link between the commands and the receiver, and houses the receiver and the individual commands as they are sent. The command is an object that encapsulates a request to the receiver. The receiver is the component that is acted upon by each request.

The intent of using command objects is to easily construct the general components that need to sequence, delegate or execute method calls at a time of their choosing without the need to know the owner of the method or the method parameters. Command design pattern provides the options to queue commands, undo/redo actions and other manipulations.

Developers might use a switch statement with a case for each command. Usage of Switch statements during coding is a sign of bad design during the design phase of an object-oriented project. Commands represent an object-oriented way to support transactions<ref>[http://www.oodesign.com/command-pattern.html Oodesign. (2005-2006)- command-pattern - http://www.oodesign.com/command-pattern.html]</ref> and can be used to solve this design problem.

== Why and When do we use a Command Pattern? ==
Command Pattern comes into picture when there is a need to store objects behaviour as a command and its state. The Command pattern encapsulates commands (method calls) in objects allowing us to issue requests without knowing the requested operation or the requesting object. Command pattern provides the options to queue commands, undo/redo actions and other manipulations.

There are several benefits<ref>[http://www.javaworld.com/javaworld/jw-06-2002/jw-0628-designpatterns.html Javaworld - Command Design Pattern - http://www.javaworld.com/javaworld/jw-06-2002/jw-0628-designpatterns.html]</ref> of using the Command pattern:

* It provides encapsulation of application logic so that it can be executed at a different point of time.

* It allows to execute the application in separate contexts, such as in a different thread or using a different state by separating the application logic and context.

* The separation between application logic and context allows to easier exchange the application logic.

Command Patterns can be used for the following:

'''Undo and redo actions'''

There is support for undo and redo of actions in certain implementations of the Command design pattern. In order to do that, a mechanism to obtain past states of the Receiver object is needed; there are two options to achieve this:
* Before running each command a snapshot of the receiver state is stored in memory. This does not require much programming effort but can not be always applied. For example doing this in an image processing application would require storing images in memory after each step, which is practically impossible.
* Instead of storing receiver objects states, the set of performed operations are stored in memory. In this case the command and receiver classes should implement the inverse algorithms to undo each action. This will require additional programming effort, but less memory will be required. Sometimes for undo/redo actions the command should store more information about the state of the receiver objects. A good idea in such cases is to use the [http://en.wikipedia.org/wiki/Memento_pattern Memento Pattern].

'''Asynchronous Method Invocation'''

Another usage for the command design pattern is to run commands asynchronous in background of an application. In this case the invoker is running in the main thread and sends the requests to the receiver which is running in a separate thread. The invoker will keep a queue of commands to be run and will send them to the receiver while it finishes running them.

Instead of using one thread in which the receiver is running more threads can be created for this. But for performance issues (thread creation is consuming) the number of threads should be limited. In this case the invoker will use a pool of receiver threads to run command asynchronously.

'''Adding new commands'''

The command object decouples the object that invokes the action from the object that performs the action. There are implementations of the pattern in which the invoker instantiates the concrete command objects. In this case if we need to add a new command type we need to change the invoker as well. And this would violate the Open Close Principle (OCP). In order to have the ability to add new commands with minimum of effort we have to make sure that the invoker is aware only about the abstract command class or interface.

'''Using composite commands'''

When adding new commands to the application we can use the [http://en.wikipedia.org/wiki/Composite_pattern composite pattern] to group existing commands in another new command. This way, macros can be created from existing commands.

==Applications==
There are many applications<ref>[http://en.wikipedia.org/wiki/Command_pattern Wikipedia. (2010, October) Wikipedia - Command_Pattern - http://en.wikipedia.org/wiki/Command_pattern]</ref> that make use of command pattern.Command objects are useful for implementing:

; In Networking : In case of computer games,player actions can to send whole command objects across the network to be executed on the other machines.
; In parallel processing : In parallel processing, tasks may be referred as the commands to a shared resource. These tasks will be executed by many threads in parallel.This can be considered as a Client/Server model.
; Graphical User Interface buttons: An [http://docs.oracle.com/javase/7/docs/api/javax/swing/Action.html Action] is a command object in case of [http://en.wikipedia.org/wiki/Swing_(Java) Swings]. A submit button, menu button or checkbox button component may be completely initialized using only the <code>Action</code> object. In a given scenario,an Action may have an icon bound to it ,mouse click,a keyboard shortcut in addition to the ability to perform the desired command.
; Multi-level [http://en.wikipedia.org/wiki/Undo undo] : The program can keep a stack of the most recently executed commands if all user actions in a program are implemented as command objects. The program simply pops the most recent command object and executes its <tt>undo()</tt> method when the user wants to undo a command.
; [http://en.wikipedia.org/wiki/Database_transaction Transactional behavior of Databases] : A database engine or software installer may keep a list of operations that have been or will be performed similar to undo.All others can be reverted or discarded if one of them fail. For instance, if two database tables that refer to each other must be updated, and the second update fails, the transaction can be rolled back, so that the first table does not now contain an invalid reference.

== Components of a command pattern ==
The various components<ref>Freeman,E., and Robson,E.,and Bates,B.,and Sierra,K. 2004. Head First Design Patterns</ref> of a command pattern are given as follows:

'''Client:''' Invokes a particular module using a command and passes a request which gets propagated as a command.

'''Command:''' It is an object that encapsulates a request to the receiver. Command request maps to particular modules. According to the command, a module is invoked.

'''Receiver:''' It is the component that is acted upon by each request. It knows how to perform the operations associated with carrying out a certain request.

'''Invoker:''' It is the class that is invoked by the client. It takes in the request and calls the receiver by passing the command to it and asks it to carry out the request.

'''Concrete Command:''' It defines a link between the receiver and the action. It basically implements the execute method and invokes the corresponding operations on the receiver.

Throughout this page, we will discuss the example of an operation of converting a string into either upper case or lower case.

<center>[[Image:WIKI.png]]</center>

The components corresponding to the example are given in the figure above. From the figure we can identify the components as follows:

'''Client:''' Menu Class is used to set the ConcreteCommand and then sets the convert class

'''Command:''' Command Class in this case is declaring the interface which is used to execute the operation.

'''Receiver:''' Convert Class is the one which knows how to perform the operations.

'''Invoker:''' TextOperation Class asks the command to carry out the action which in this case is to either convert toUpper or toLower.

'''ConcreteCommand:''' ConvertUpper, ConvertLower classes are the ones that implement the execute command.

==Terminology==

The terminology used to describe command pattern implementations can be confusing sometimes.
* '''Command Object, Routed Command Object and Action Object''': In this, we can refer a singleton object which knows about mouse click , button images, shortcut keys and so on related to the command. A invoker object calls the Action object's performAction method.When the availability of a command/action has changed, the Command/Action object notifies the appropriate source/invoker objects.When a command/action cannot be executed/performed, this allows buttons and menu items to become inactive.
* '''Client, Source and Invoker''': It refers to a button, toolbar button, or radio button clicked, or the shortcut key pressed by the user.
* '''Receiver, Target Object''': This is the object that is about will be copied, pasted or perform some other function . The receiver object owns the method that is called by the command's ''execute'' method. The receiver is also the target object. For instance, if the receiver object is a ''cursor'' and the method is called ''moveDown'', then one would expect that the cursor is the target of the moveDown action.
* '''Handler, method, ''': This is the actual code that does the copying, pasting etc.There are many variants of the handler. This is the handler code of the action object in some implementations. In other implementations the code is part of the Receiver/Target Object.Finally in some other implementations the handler code is kept separate from the other objects.

== Check list for Command Pattern Implementation ==

* Define a Command interface with a method signature like <code>execute()</code>.
* 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 the Command object from the creator (aka sender) to the invoker (aka receiver).
* The invoker decides when to <code>execute()</code>.

== Rules of thumb<ref>Erich,G., and Richard,H.,and Ralph,J.,and John,M.V. 1997. Design Patterns: Elements of Reusable Object-Oriented Software</ref> ==

*[http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern Chain of Responsibility], Command, [http://en.wikipedia.org/wiki/Mediator_pattern Mediator], and [http://en.wikipedia.org/wiki/Observer_pattern Observer], address how you can decouple senders and receivers, but with different trade-offs. *Command normally specifies a sender-receiver connection with a subclass.
*Chain of Responsibility can use Command to represent requests as objects.
*Command and Memento act as magic tokens to be passed around and invoked at a later time. In Command, the token represents a request; in *Memento, it represents the internal state of an object at a particular time. Polymorphism is important to Command, but not to Memento because its interface is so narrow that a memento can only be passed as a value.
*Command can use Memento to maintain the state required for an undo operation.
*MacroCommands can be implemented with Composite.
*A Command that must be copied before being placed on a history list acts as a Prototype.
*Two important aspects of the Command pattern: interface separation (the invoker is isolated from the receiver), time separation (stores a ready-to-go processing request that’s to be stated later).

== Example of Command pattern ==

Consider the case of converting a string to upper and lower case.The Client is the Menu where we see the options. The menu sends the request to the receiver(convert class) through the Invoker(TextOperations class). The textOperation encapsulates the command and then forwards it, creating the ConcreteCommand object which is the command itself. The Receiver will be the Convert class that, after completing all the commands that were sent to it before the command in question(to Upper case or to lower case ), starts to work on it.

== Implementation in static and dynamic languages ==

=== Implementation in Static languages ===
We initially define a Command interface with a method named execute() and then we create command classes that implement this interface. The execute() method of each object will contain the logic specific to the action you are encapsulating.
(For instance, you might create a convertUpper and a converLower command in a text editor application.)

In case of the static implementation, code snippets to implement the command pattern in languages like Java and C# are given as follows:

==== Java Example ====
This contains the '''Command interface''' with a method named <code>execute()</code> and then we create command classes that implement this interface.
<pre>
public interface Command{
void execute();
}
//A command to convert to lower case.
public class convertLower implements Command{
private Convert convert;
private convertLower(Convert conv){
this.convert = conv;
}
public void execute(){
convert.toLower();
}
}
//A command to convert to upper case
public class convertUpper implements Command{
private Convert convert;
private convertUpper(Convert conv){
this.convert = conv;
}
public void execute(){
convert.toUpper();
}
}
</pre>
This is the '''invoker class''' which contains the method <code>commandExecute()</code> that takes Command object as parameter and asks the Command to carry out the action by executing its <code>execute()</code>.
<pre>
public class TextOperations{
private ArrayList<Command> Command_List= new ArrayList<Command>;
private TextOperations(){
}
public void commandExecute(Command cmd){
this.Command_List.add(cmd); // optional
cmd.execute();
}
}
</pre>
This is the '''receiver class''' which knows how to perform the operations. Here receiver class has the implementation of <code>toUpper()</code> and <code>toLower()</code>
<pre>
public class Convert{
public Convert(){
}
public final void toUpper(){
System.out.print("Turning all lower case elements to upper case");//The actual action that is being performed.
}
public final void toLower(){
System.out.print("Converting all upper case elements to lower case");//The actual action that is being performed.
}
}
</pre>
This is the '''client class''' which creates object of class Convert and calls the <code>commandExecute()</code> method based on the argument passed in command line
<pre>
public class Menu{
public static void main(String[] args){
Convert c = new Convert();
Command conToUpper = new convertUpper(c);
Command conToLower = new convertLower(c);

TextOperations converter = new TextOperations();
if (args[0].equalsIgnoreCase("ToUpper")) {
converter.commandExecute(conToUpper);
System.exit(0);
}
if (args[0].equalsIgnoreCase("ToLower")) {
converter.commandExecute(conToLower);
System.exit(0);
}
}
}
</pre>

==== C# Example ====
This contains the '''Command interface''' with a method named <code>execute()</code> and then we create command classes that implement this interface.
<pre>
public interface Command
{
void execute(); //The execute method that is going to call the action
}

//A command to convert to lower case.
public class convertLower : Command{
private Convert convert;
private convertLower(Convert conv){
this.convert = conv;
}
public void execute(){
convert.toLower();
}
}
//A command to convert to upper case
public class convertUpper : Command{
private Convert convert;
private convertUpper(Convert conv){
this.convert = conv;
}
public void execute(){
convert.toUpper();
}
}
</pre>
This is the '''invoker class''' which contains method <code>commandExecute()</code> that takes Command object as the parameter and asks the Command to carry out the action by executing its <code>execute()</code> function.
<pre>
public class TextOperations{
private ArrayList<Command> _command_List= new ArrayList<Command>;
private TextOperations(){
}
public void commandExecute(Command cmd){
_commands.add(cmd); // optional
cmd.execute();
}
}
</pre>
This is the '''receiver class''' which knows how to perform the operations. Here receiver class has the implementation of <code>toUpper()</code> and <code>toLower()</code>
<pre>
public class Convert{
public Convert(){
}
public final void toUpper(){
Console.WriteLine("Turning all lower case elements to upper case");// These are the actual actions that are performed
}
public final void toLower(){
Console.WriteLine("Converting all upper case elements to lower case"); //These is the actual action that is performed
}
}
</pre>
This is the '''client class''' which creates object of class Convert and calls the <code>commandExecute()</code> method based on the argument passed in command line
<pre>
public class Menu
{
Static void Main(string[] args)
{
Convert c = new Convert();
Command conToUpper = new convertUpper(c);
Command conToLower = new convertLower(c);
TextOperations converter = new TextOperations(); /*Client calls the invoker and gives the commands to execute*/
if (args[0].ToUpper().Equals("toUpper"))
{
converter.commandExecute(conToUpper);
return;
}
if (args[0].ToUpper().Equals("tolower"))
{
converter.commandExecute(conToLower);
return;
}
}
}
</pre>

=== Implementation in Dynamic Languages ===

In [http://en.wikipedia.org/wiki/Dynamic_programming_language dynamic languages] we will have a controller class that constructs each of the Command objects.Each of these command objects is passed to an invoker class. The invoker class calls the execute() method of a Command object at the appropriate time.
(For instance this may happen when a user selects a menu item or presses a button)

In case of the dynamic languages, the code snippets to implement command pattern for ruby and python are given as follows.

==== Ruby Example ====
This contains the '''Command class''' with a method named <code>execute()</code> and then we create derived classes that inherit from the Command class.
<pre>
class Command
def execute()
end
end
class convertLower < Command
def initialize(conv)
self.@convert = conv
end

def execute()
@convert.toLower()
end
end
class convertUpper < Command
def initialize(conv)
self.@convert = conv
end

def execute()
@convert.toUpper()
end
end
</pre>
This is the '''receiver class''' which knows how to perform the operations. Here receiver class has the implementation of <code>toUpper()</code> and <code>toLower()</code>
<pre>
class Convert
def initialize()
end

def toUpper()
Console.WriteLine("Turning all lower case elements to upper case")
end

def toLower()
Console.WriteLine("Converting all upper case elements to lower case")
end
end
</pre>
This is the '''invoker class''' which contains the method <code>commandExecute()</code> that takes Command object as parameter and asks the Command to carry out the action by executing its <code>execute()</code>.
<pre>
class TextOperations
def initialize(toup, todwn)
self.@convertUp = toup
self.@convertLow = todwn
end

def convToUp()
@convertUp.execute()
end

def convToLow()
@convertLow.execute()
end
end
</pre>
This is the '''client class''' which creates object of class Convert and calls the <code>commandExecute()</code> method based on the argument passed in command line
<pre>
class Menu
def Main(args)
c = Convert.new()
cou = convertUpper.new(c)
col = convertLower.new(c)
converter = TextOperations.new(cou, col) # Client calls the invoker and gives the commands to execute
converter.convToLow()
converter.convToUp()
end
end
</pre>

==== Python Example ====
This contains the '''Command class''' with a method named <code>execute()</code> and then we create derived classes that inherit from the Command class.
<pre>
class Command(object):
def execute(self):
pass

class convertLower(Command):
def __init__(self, conv):
self._convert = conv

def execute(self):
self._convert.toLower()
class convertUpper(Command):
def __init__(self, conv):
self._convert = conv

def execute(self):
self._convert.toUpper()
</pre>
This is the '''receiver class''' which knows how to perform the operations. Here receiver class has the implementation of <code>toUpper()</code> and <code>toLower()</code>
<pre>
class Convert(object):
def __init__(self):
pass
def toUpper(self):
Console.WriteLine("Turning all lower case elements to upper case")

def toLower(self):
Console.WriteLine("Converting all upper case elements to lower case")
</pre>
This is the '''invoker class''' which contains the method <code>commandExecute()</code> that takes Command object as parameter and asks the Command to carry out the action by executing its <code>execute()</code>.
<pre>
class TextOperations(object):
def __init__(self, toup, todwn):
self._convertUp = toup
self._convertLow = todwn

def convToUp(self):
self._convertUp.execute()

def convToLow(self):
self._convertLow.execute()
</pre>
This is the '''client class''' which creates object of class Convert and calls the <code>commandExecute()</code> method based on the argument passed in command line
<pre>
class Menu(object):
def Main(self, args):
c = Convert()
cou = convertUpper(c)
col = convertLower(c)
converter = TextOperations(cou, col) # Client calls the invoker and gives the commands to execute
converter.convToLow()
converter.convToUp()
</pre>

=== Static vs Dynamic implementations ===
In case of the implementations ruby has better implementation of the command patterns than the languages like Java. Some of the advantages of Ruby over Java can be given as follows.
* To implement the command pattern in static languages like Java, we have to define a common interface which has to be extended by all the other classes. In case of ruby we can use procs which makes it easier to implement.
* Ruby implements something called mixins in order to implement the command pattern which is efficient compared to Java.
* The lines of code for static language like Java is more than that taken by the dynamic language like Ruby. This is more because of the proc objects that are present in ruby which are concisely defined than that present in Java.
* Since Ruby is a dynamic language, one can add the commands to the command array during runtime. Java is a static language and hence does not support this feature.

=== Conclusion ===
Hence it can be summarized that the dynamically typed languages keep the code straight and narrow as it does not need to depend on static type-checking. Also due to the flexibility of the dynamic languages, writing code is significantly easier.

== See Also ==
* [http://en.wikipedia.org/wiki/Design_pattern_(computer_science) Design Pattern]
* [http://en.wikipedia.org/wiki/Software_design_pattern Software Design Pattern]
* [http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern Chain of Responsibility Pattern]
* [http://en.wikipedia.org/wiki/Mediator_pattern Mediator Pattern]
* [http://en.wikipedia.org/wiki/Observer_pattern Observer Pattern]
* [http://en.wikipedia.org/wiki/Composite_pattern Composite Pattern]
* [http://en.wikipedia.org/wiki/Memento_pattern Memento Pattern]

== References ==
<references/>

== Additional Reading ==

* [http://www.codeproject.com/Articles/15207/Design-Patterns-Command-Pattern Design Pattern: Command Pattern] at codeproject.com
* [http://java.dzone.com/articles/design-patterns-command Command Pattern in Java] at java.dzone.com
* [http://www.cs.mcgill.ca/~hv/classes/CS400/01.hchen/doc/command/command.html Basics of Command Pattern]
* [http://www.dofactory.com/Patterns/PatternCommand.aspx Command Pattern in C#] at dofactory.com

* [http://sourcemaking.com/design_patterns/command Behavorial Design Pattern - Command Pattern] at sourcemaking.com

* [http://perfectjpattern.sourceforge.net/dp-command.html GoF Command Pattern]

* McDonald,J. 2008. Design Patterns

CSC/ECE 517 Fall 2012/ch1b 1w52 an

2012-11-20T01:03:48Z

Aasawa:

== '''Command Pattern ''' ==

Command Pattern is a [http://en.wikipedia.org/wiki/Design_pattern_(computer_science) design pattern] in [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming] in which an object is used to represent and [http://en.wikipedia.org/wiki/Encapsulation_(computer_science)#Encapsulation encapsulate] all the information needed to call a method at a later time. This information comprises of, the method name, the object that is the owner of the method and values for the method parameters. It encapsulates a request as an object and gives it a known public interface. It ensures that every object receives its own commands and provides a [http://en.wikipedia.org/wiki/Decoupling#Software_Development decoupling] between sender and receiver. In this case a sender is an object that invokes an operation, and a receiver is an object that receives the request and acts on it.

There are three main components of a Command pattern: the ''Invoker'', the ''Command'', and the ''Receiver''. The invoker component acts as a link between the commands and the receiver, and houses the receiver and the individual commands as they are sent. The command is an object that encapsulates a request to the receiver. The receiver is the component that is acted upon by each request.

The intent of using command objects is to easily construct the general components that need to sequence, delegate or execute method calls at a time of their choosing without the need to know the owner of the method or the method parameters. Command design pattern provides the options to queue commands, undo/redo actions and other manipulations.

Developers might use a switch statement with a case for each command. Usage of Switch statements during coding is a sign of bad design during the design phase of an object-oriented project. Commands represent an object-oriented way to support transactions<ref>[http://www.oodesign.com/command-pattern.html Oodesign. (2005-2006)- command-pattern - http://www.oodesign.com/command-pattern.html]</ref> and can be used to solve this design problem.

== Why and When do we use a Command Pattern? ==
Command Pattern comes into picture when there is a need to store objects behaviour as a command and its state. The Command pattern encapsulates commands (method calls) in objects allowing us to issue requests without knowing the requested operation or the requesting object. Command pattern provides the options to queue commands, undo/redo actions and other manipulations.

There are several benefits<ref>[http://www.javaworld.com/javaworld/jw-06-2002/jw-0628-designpatterns.html Javaworld - Command Design Pattern - http://www.javaworld.com/javaworld/jw-06-2002/jw-0628-designpatterns.html]</ref> of using the Command pattern:

* It provides encapsulation of application logic so that it can be executed at a different point of time.

* It allows to execute the application in separate contexts, such as in a different thread or using a different state by separating the application logic and context.

* The separation between application logic and context allows to easier exchange the application logic.

Command Patterns can be used for the following:

'''Undo and redo actions'''

There is support for undo and redo of actions in certain implementations of the Command design pattern. In order to do that, a mechanism to obtain past states of the Receiver object is needed; there are two options to achieve this:
* Before running each command a snapshot of the receiver state is stored in memory. This does not require much programming effort but can not be always applied. For example doing this in an image processing application would require storing images in memory after each step, which is practically impossible.
* Instead of storing receiver objects states, the set of performed operations are stored in memory. In this case the command and receiver classes should implement the inverse algorithms to undo each action. This will require additional programming effort, but less memory will be required. Sometimes for undo/redo actions the command should store more information about the state of the receiver objects. A good idea in such cases is to use the [http://en.wikipedia.org/wiki/Memento_pattern Memento Pattern].

'''Asynchronous Method Invocation'''

Another usage for the command design pattern is to run commands asynchronous in background of an application. In this case the invoker is running in the main thread and sends the requests to the receiver which is running in a separate thread. The invoker will keep a queue of commands to be run and will send them to the receiver while it finishes running them.

Instead of using one thread in which the receiver is running more threads can be created for this. But for performance issues (thread creation is consuming) the number of threads should be limited. In this case the invoker will use a pool of receiver threads to run command asynchronously.

'''Adding new commands'''

The command object decouples the object that invokes the action from the object that performs the action. There are implementations of the pattern in which the invoker instantiates the concrete command objects. In this case if we need to add a new command type we need to change the invoker as well. And this would violate the Open Close Principle (OCP). In order to have the ability to add new commands with minimum of effort we have to make sure that the invoker is aware only about the abstract command class or interface.

'''Using composite commands'''

When adding new commands to the application we can use the [http://en.wikipedia.org/wiki/Composite_pattern composite pattern] to group existing commands in another new command. This way, macros can be created from existing commands.

==Applications==
There are many applications<ref>[http://en.wikipedia.org/wiki/Command_pattern Wikipedia. (2010, October) Wikipedia - Command_Pattern - http://en.wikipedia.org/wiki/Command_pattern]</ref> that make use of command pattern.Command objects are useful for implementing:

; In Networking : In case of computer games,player actions can to send whole command objects across the network to be executed on the other machines.
; In parallel processing : In parallel processing, tasks may be referred as the commands to a shared resource. These tasks will be executed by many threads in parallel.This can be considered as a Client/Server model.
; Graphical User Interface buttons: An [http://docs.oracle.com/javase/7/docs/api/javax/swing/Action.html Action] is a command object in case of [http://en.wikipedia.org/wiki/Swing_(Java) Swings]. A submit button, menu button or checkbox button component may be completely initialized using only the <code>Action</code> object. In a given scenario,an Action may have an icon bound to it ,mouse click,a keyboard shortcut in addition to the ability to perform the desired command.
; Multi-level [http://en.wikipedia.org/wiki/Undo undo] : The program can keep a stack of the most recently executed commands if all user actions in a program are implemented as command objects. The program simply pops the most recent command object and executes its <tt>undo()</tt> method when the user wants to undo a command.
; [http://en.wikipedia.org/wiki/Database_transaction Transactional behavior of Databases] : A database engine or software installer may keep a list of operations that have been or will be performed similar to undo.All others can be reverted or discarded if one of them fail. For instance, if two database tables that refer to each other must be updated, and the second update fails, the transaction can be rolled back, so that the first table does not now contain an invalid reference.

== Components of a command pattern ==
The various components<ref>Freeman,E., and Robson,E.,and Bates,B.,and Sierra,K. 2004. Head First Design Patterns</ref> of a command pattern are given as follows:

'''Client:''' Invokes a particular module using a command and passes a request which gets propagated as a command.

'''Command:''' It is an object that encapsulates a request to the receiver. Command request maps to particular modules. According to the command, a module is invoked.

'''Receiver:''' It is the component that is acted upon by each request. It knows how to perform the operations associated with carrying out a certain request.

'''Invoker:''' It is the class that is invoked by the client. It takes in the request and calls the receiver by passing the command to it and asks it to carry out the request.

'''Concrete Command:''' It defines a link between the receiver and the action. It basically implements the execute method and invokes the corresponding operations on the receiver.

Throughout this page, we will discuss the example of an operation of converting a string into either upper case or lower case.

<center>[[Image:WIKI.png]]</center>

The components corresponding to the example are given in the figure above. From the figure we can identify the components as follows:

'''Client:''' Menu Class is used to set the ConcreteCommand and then sets the convert class

'''Command:''' Command Class in this case is declaring the interface which is used to execute the operation.

'''Receiver:''' Convert Class is the one which knows how to perform the operations.

'''Invoker:''' TextOperation Class asks the command to carry out the action which in this case is to either convert toUpper or toLower.

'''ConcreteCommand:''' ConvertUpper, ConvertLower classes are the ones that implement the execute command.

==Terminology==

The terminology used to describe command pattern implementations can be confusing sometimes.
* '''Command Object, Routed Command Object and Action Object''': In this, we can refer a singleton object which knows about mouse click , button images, shortcut keys and so on related to the command. A invoker object calls the Action object's performAction method.When the availability of a command/action has changed, the Command/Action object notifies the appropriate source/invoker objects.When a command/action cannot be executed/performed, this allows buttons and menu items to become inactive.
* '''Client, Source and Invoker''': It refers to a button, toolbar button, or radio button clicked, or the shortcut key pressed by the user.
* '''Receiver, Target Object''': This is the object that is about will be copied, pasted or perform some other function . The receiver object owns the method that is called by the command's ''execute'' method. The receiver is also the target object. For instance, if the receiver object is a ''cursor'' and the method is called ''moveDown'', then one would expect that the cursor is the target of the moveDown action.
* '''Handler, method, ''': This is the actual code that does the copying, pasting etc.There are many variants of the handler. This is the handler code of the action object in some implementations. In other implementations the code is part of the Receiver/Target Object.Finally in some other implementations the handler code is kept separate from the other objects.

== Check list for Command Pattern Implementation ==

* Define a Command interface with a method signature like <code>execute()</code>.
* 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 the Command object from the creator (aka sender) to the invoker (aka receiver).
* The invoker decides when to <code>execute()</code>.

== Rules of thumb<ref>Erich,G., and Richard,H.,and Ralph,J.,and John,M.V. 1997. Design Patterns: Elements of Reusable Object-Oriented Software</ref> ==

*[http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern Chain of Responsibility], Command, [http://en.wikipedia.org/wiki/Mediator_pattern Mediator], and [http://en.wikipedia.org/wiki/Observer_pattern Observer], address how you can decouple senders and receivers, but with different trade-offs. *Command normally specifies a sender-receiver connection with a subclass.
*Chain of Responsibility can use Command to represent requests as objects.
*Command and Memento act as magic tokens to be passed around and invoked at a later time. In Command, the token represents a request; in *Memento, it represents the internal state of an object at a particular time. Polymorphism is important to Command, but not to Memento because its interface is so narrow that a memento can only be passed as a value.
*Command can use Memento to maintain the state required for an undo operation.
*MacroCommands can be implemented with Composite.
*A Command that must be copied before being placed on a history list acts as a Prototype.
*Two important aspects of the Command pattern: interface separation (the invoker is isolated from the receiver), time separation (stores a ready-to-go processing request that’s to be stated later).

== Example of Command pattern ==

Consider the case of converting a string to upper and lower case.The Client is the Menu where we see the options. The menu sends the request to the receiver(convert class) through the Invoker(TextOperations class). The textOperation encapsulates the command and then forwards it, creating the ConcreteCommand object which is the command itself. The Receiver will be the Convert class that, after completing all the commands that were sent to it before the command in question(to Upper case or to lower case ), starts to work on it.

== Implementation in static and dynamic languages ==

=== Implementation in Static languages ===
We initially define a Command interface with a method named execute() and then we create command classes that implement this interface. The execute() method of each object will contain the logic specific to the action you are encapsulating.
(For instance, you might create a convertUpper and a converLower command in a text editor application.)

In case of the static implementation, code snippets to implement the command pattern in languages like Java and C# are given as follows:

==== Java Example ====
This contains the '''Command interface''' with a method named <code>execute()</code> and then we create command classes that implement this interface.
<pre>
public interface Command{
void execute();
}
//A command to convert to lower case.
public class convertLower implements Command{
private Convert convert;
private convertLower(Convert conv){
this.convert = conv;
}
public void execute(){
convert.toLower();
}
}
//A command to convert to upper case
public class convertUpper implements Command{
private Convert convert;
private convertUpper(Convert conv){
this.convert = conv;
}
public void execute(){
convert.toUpper();
}
}
</pre>
This is the '''invoker class''' which contains the method <code>commandExecute()</code> that takes Command object as parameter and asks the Command to carry out the action by executing its <code>execute()</code>.
<pre>
public class TextOperations{
private ArrayList<Command> Command_List= new ArrayList<Command>;
private TextOperations(){
}
public void commandExecute(Command cmd){
this.Command_List.add(cmd); // optional
cmd.execute();
}
}
</pre>
This is the '''receiver class''' which knows how to perform the operations. Here receiver class has the implementation of <code>toUpper()</code> and <code>toLower()</code>
<pre>
public class Convert{
public Convert(){
}
public final void toUpper(){
System.out.print("Turning all lower case elements to upper case");//The actual action that is being performed.
}
public final void toLower(){
System.out.print("Converting all upper case elements to lower case");//The actual action that is being performed.
}
}
</pre>
This is the '''client class''' which creates object of class Convert and calls the <code>commandExecute()</code> method based on the argument passed in command line
<pre>
public class Menu{
public static void main(String[] args){
Convert c = new Convert();
Command conToUpper = new convertUpper(c);
Command conToLower = new convertLower(c);

TextOperations converter = new TextOperations();
if (args[0].equalsIgnoreCase("ToUpper")) {
converter.commandExecute(conToUpper);
System.exit(0);
}
if (args[0].equalsIgnoreCase("ToLower")) {
converter.commandExecute(conToLower);
System.exit(0);
}
}
}
</pre>

==== C# Example ====
This contains the '''Command interface''' with a method named <code>execute()</code> and then we create command classes that implement this interface.
<pre>
public interface Command
{
void execute(); //The execute method that is going to call the action
}

//A command to convert to lower case.
public class convertLower : Command{
private Convert convert;
private convertLower(Convert conv){
this.convert = conv;
}
public void execute(){
convert.toLower();
}
}
//A command to convert to upper case
public class convertUpper : Command{
private Convert convert;
private convertUpper(Convert conv){
this.convert = conv;
}
public void execute(){
convert.toUpper();
}
}
</pre>
This is the '''invoker class''' which contains method <code>commandExecute()</code> that takes Command object as the parameter and asks the Command to carry out the action by executing its <code>execute()</code> function.
<pre>
public class TextOperations{
private ArrayList<Command> _command_List= new ArrayList<Command>;
private TextOperations(){
}
public void commandExecute(Command cmd){
_commands.add(cmd); // optional
cmd.execute();
}
}
</pre>
This is the '''receiver class''' which knows how to perform the operations. Here receiver class has the implementation of <code>toUpper()</code> and <code>toLower()</code>
<pre>
public class Convert{
public Convert(){
}
public final void toUpper(){
Console.WriteLine("Turning all lower case elements to upper case");// These are the actual actions that are performed
}
public final void toLower(){
Console.WriteLine("Converting all upper case elements to lower case"); //These is the actual action that is performed
}
}
</pre>
This is the '''client class''' which creates object of class Convert and calls the <code>commandExecute()</code> method based on the argument passed in command line
<pre>
public class Menu
{
Static void Main(string[] args)
{
Convert c = new Convert();
Command conToUpper = new convertUpper(c);
Command conToLower = new convertLower(c);
TextOperations converter = new TextOperations(); /*Client calls the invoker and gives the commands to execute*/
if (args[0].ToUpper().Equals("toUpper"))
{
converter.commandExecute(conToUpper);
return;
}
if (args[0].ToUpper().Equals("tolower"))
{
converter.commandExecute(conToLower);
return;
}
}
}
</pre>

=== Implementation in Dynamic Languages ===

In [http://en.wikipedia.org/wiki/Dynamic_programming_language dynamic languages] we will have a controller class that constructs each of the Command objects.Each of these command objects is passed to an invoker class. The invoker class calls the execute() method of a Command object at the appropriate time.
(For instance this may happen when a user selects a menu item or presses a button)

In case of the dynamic languages, the code snippets to implement command pattern for ruby and python are given as follows.

==== Ruby Example ====
This contains the '''Command class''' with a method named <code>execute()</code> and then we create derived classes that inherit from the Command class.
<pre>
class Command
def execute()
end
end
class convertLower < Command
def initialize(conv)
self.@convert = conv
end

def execute()
@convert.toLower()
end
end
class convertUpper < Command
def initialize(conv)
self.@convert = conv
end

def execute()
@convert.toUpper()
end
end
</pre>
This is the '''receiver class''' which knows how to perform the operations. Here receiver class has the implementation of <code>toUpper()</code> and <code>toLower()</code>
<pre>
class Convert
def initialize()
end

def toUpper()
Console.WriteLine("Turning all lower case elements to upper case")
end

def toLower()
Console.WriteLine("Converting all upper case elements to lower case")
end
end
</pre>
This is the '''invoker class''' which contains the method <code>commandExecute()</code> that takes Command object as parameter and asks the Command to carry out the action by executing its <code>execute()</code>.
<pre>
class TextOperations
def initialize(toup, todwn)
self.@convertUp = toup
self.@convertLow = todwn
end

def convToUp()
@convertUp.execute()
end

def convToLow()
@convertLow.execute()
end
end
</pre>
This is the '''client class''' which creates object of class Convert and calls the <code>commandExecute()</code> method based on the argument passed in command line
<pre>
class Menu
def Main(args)
c = Convert.new()
cou = convertUpper.new(c)
col = convertLower.new(c)
converter = TextOperations.new(cou, col) # Client calls the invoker and gives the commands to execute
converter.convToLow()
converter.convToUp()
end
end
</pre>

==== Python Example ====
This contains the '''Command class''' with a method named <code>execute()</code> and then we create derived classes that inherit from the Command class.
<pre>
class Command(object):
def execute(self):
pass

class convertLower(Command):
def __init__(self, conv):
self._convert = conv

def execute(self):
self._convert.toLower()
class convertUpper(Command):
def __init__(self, conv):
self._convert = conv

def execute(self):
self._convert.toUpper()
</pre>
This is the '''receiver class''' which knows how to perform the operations. Here receiver class has the implementation of <code>toUpper()</code> and <code>toLower()</code>
<pre>
class Convert(object):
def __init__(self):
pass
def toUpper(self):
Console.WriteLine("Turning all lower case elements to upper case")

def toLower(self):
Console.WriteLine("Converting all upper case elements to lower case")
</pre>
This is the '''invoker class''' which contains the method <code>commandExecute()</code> that takes Command object as parameter and asks the Command to carry out the action by executing its <code>execute()</code>.
<pre>
class TextOperations(object):
def __init__(self, toup, todwn):
self._convertUp = toup
self._convertLow = todwn

def convToUp(self):
self._convertUp.execute()

def convToLow(self):
self._convertLow.execute()
</pre>
This is the '''client class''' which creates object of class Convert and calls the <code>commandExecute()</code> method based on the argument passed in command line
<pre>
class Menu(object):
def Main(self, args):
c = Convert()
cou = convertUpper(c)
col = convertLower(c)
converter = TextOperations(cou, col) # Client calls the invoker and gives the commands to execute
converter.convToLow()
converter.convToUp()
</pre>

=== Static vs Dynamic implementations ===
In case of the implementations ruby has better implementation of the command patterns than the languages like Java. Some of the advantages of Ruby over Java can be given as follows.
* To implement the command pattern in static languages like Java, we have to define a common interface which has to be extended by all the other classes. In case of ruby we can use procs which makes it easier to implement.
* Ruby implements something called mixins in order to implement the command pattern which is efficient compared to Java.
* The lines of code for static language like Java is more than that taken by the dynamic language like Ruby. This is more because of the proc objects that are present in ruby which are concisely defined than that present in Java.
* Since Ruby is a dynamic language, one can add the commands to the command array during runtime. Java is a static language and hence does not support this feature.

=== Conclusion ===
Hence it can be summarized that the dynamically typed languages keep the code straight and narrow as it does not need to depend on static type-checking. Also due to the flexibility of the dynamic languages, writing code is significantly easier.

== See Also ==
* [http://en.wikipedia.org/wiki/Design_pattern_(computer_science) Design Pattern]
* [http://en.wikipedia.org/wiki/Software_design_pattern Software Design Pattern]
* [http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern Chain of Responsibility Pattern]
* [http://en.wikipedia.org/wiki/Mediator_pattern Mediator Pattern]
* [http://en.wikipedia.org/wiki/Observer_pattern Observer Pattern]
* [http://en.wikipedia.org/wiki/Composite_pattern Composite Pattern]
* [http://en.wikipedia.org/wiki/Memento_pattern Memento Pattern]

== References ==
<references/>

== Additional Reading ==

* [http://www.dofactory.com/topic/1675/facade-with-factory-pattern.aspx Facade with Factory pattern in Java] at java.dzone.com
* [http://www.cs.mcgill.ca/~hv/classes/CS400/01.hchen/doc/command/command.html Basics of Command Pattern]
* [http://www.dofactory.com/Patterns/PatternCommand.aspx Command Pattern in C#] at dofactory.com

* [http://sourcemaking.com/design_patterns/command Behavorial Design Pattern - Command Pattern] at sourcemaking.com

* [http://perfectjpattern.sourceforge.net/dp-command.html GoF Command Pattern]

* McDonald,J. 2008. Design Patterns

CSC/ECE 517 Fall 2012/ch2b 2w42 aa

2012-11-20T01:02:32Z

Aasawa:

=Introduction =

==Facade Pattern==
Intent 
* Provide a unified interface to a set of interfaces in a subsystem. 
* Wrap a complicated subsystem with a simpler interface. 

Facade discusses encapsulating a complex subsystem within a single interface object. This reduces the learning curve necessary to successfully leverage the subsystem. It also promotes decoupling the subsystem from its potentially many clients. On the other hand, if the Facade is the only access point for the subsystem, it will limit the features and flexibility that “power users” may need. The Facade object should be a fairly simple advocate or facilitator. It should not become an all-knowing oracle or “god” object. 

== Adapter Pattern ==

Intent 
* Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn’t otherwise because of incompatible interfaces. 
* Wrap an existing class with a new interface. 
* Impedance match an old component to a new system. 

Convert the interface of a class into another interface clients expect. Adapter lets classes worktogether that couldn't otherwise because of incompatible interfaces.

==Abstract Factory Pattern==

Intent 
* Provide an interface for creating families of related or dependent objects without specifying their concrete classes. 
* A hierarchy that encapsulates: many possible “platforms”, and the construction of a suite of “products”. 
* The new operator considered harmful. 

If an application is to be portable, it needs to encapsulate platform dependencies. These “platforms” might include: windowing system, operating system, database, etc. Too often, this encapsulatation is not engineered in advance, and lots of #ifdef case statements with options for all currently supported platforms begin to procreate like rabbits throughout the code. 

==Mediator Pattern==
Intent 

* Define an object that encapsulates how a set of objects interact. Mediator promotes loose coupling by keeping objects from referring to each other explicitly, and it lets you vary their interaction independently.
* Design an intermediary to decouple many peers.
* Promote the many-to-many relationships between interacting peers to “full object status”.

=Facade Pattern =

==Non-Software examples<ref>[http://aspalliance.com/970_Facade_Design_Pattern.2 ASPAlliance - Facade Design Pattern - http://aspalliance.com/970_Facade_Design_Pattern.2]</ref>==
In most of the Pizza centers, orders will be given through phone calls with the customer interacting with the Customer service representative. In this case, consumers do not have access to the Billing system, Kitchen and delivery department. The customer service representative acts as an interface and interacts with each of the departments involved in the transaction and ensures that Pizzas are delivered to the consumer. Customer Service representative corresponds to the facade. Individual departments involved in the transaction correspond to Sub-systems.

==Software examples==
Web Service Facade Solution Architecture provides an example for Facade design pattern. In this architectural solution, instead of rewriting legacy applications or customizing those with middleware to connect to other applications one by one, this solution helps create a "facade" for the legacy application. Other applications are easily "plugged into" this facade. By modeling a legacy application into its basic functions of create, read, update, and delete and then exposing these functions as Web methods, the Web service facade solution allows other applications to access legacy data by making use of common Web services through standardized protocols. In this way, Facade decouples layers so that they do not depend on each other which can make it easier to develop, to use and to promote code re-use.

== C# Example ==
using System;
using System.Collections.Generic; 
namespace DesignPatterns.Facade
{
public class OrderFacade
{
//Places an Order and Returns an Order ID
public int placeOrder(int CustomerID, List<BasketItem> Products)
{
Order anOrder = new Order();
OrderLine anOrderLine = new OrderLine();
Address DespatchAddress = Address.getCustomerDespatchAddress(CustomerID);
int OrderId = anOrder.requestOrderID();
anOrder.createOrder(OrderId, DespatchAddress);
anOrderLine.addOrderLinesToOrder(OrderId, Products);
return OrderId;
}
} 
//order class
public class Order
{
public int requestOrderID()
{
//Creates and Returns a Unique Order ID
} 
public void createOrder(int OrderId, Address DespatchAddress)
{
}
} 
//OrderLine Class
public class OrderLine
{
public void addOrderLinesToOrder(int OrderId, List<BasketItem> Products)
{
}
} 
//Public Customer
public class Address
{
public static Address getCustomerDespatchAddress(int CustomerID)
{
return new Address();
}
//Address properties
} 
public class BasketItem
{
//BasketItem Properties
}
}

=Adapter Pattern and Facade Pattern =

Adapter functions as a wrapper or modifier of an existing class. It provides a different or translated view of that class. 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. Reuse has always been painful and elusive. One reason has been the tribulation of designing something new, while reusing something old. There is always something not quite right between the old and the new. It may be physical dimensions or misalignment. It may be timing or synchronization. It may be unfortunate assumptions or competing standards. It is like the problem of inserting a new three-prong electrical plug in an old two-prong wall outlet – some kind of adapter or intermediary is necessary. 

Adapter is about creating an intermediary abstraction that translates, or maps, the old component to the new system. Clients call methods on the Adapter object which redirects them into calls to the legacy component. This strategy can be implemented either with inheritance or with aggregation. 

== Adapter Pattern Example ==
<pre>
interface Shape {
void draw(...);
}

Class LegacyLine {
void draw(..) { }
}

Class LegacyRectangle {
void draw(..) { }
}

Class Line implements Shape {
adapter = new LegacyLine();
void draw(...) {adapter.draw(...)}
}

Class Rectangle implements Shape {
adapter = new LegacyRectangle();
void draw(...) {adapter.draw(...)}
}
</pre>

In the example provided for the Facade pattern, the method placeOrder() uses the methods exposed by many other classes such as Order, OrderLine, Address etc to provide a high level view for the callers. The callers need not worry about the complexities in handling the sub-system. The users of the Class OrderFacade just invoke the method placeOrder() with the necessary arguments and rest of the process is taken care by placeOrder(). As can be seen in this case, a new method (placeOrder) was defined which has the logic and the necessary steps to handle all the sub-systems to create an order, create an id for the order, create a dispatch address etc.

In the example provided for the Adapter pattern, no new methods are defined. The existing method draw of LegacyRectangle is wrapped in a adapter class Rectangle. The methods in adapter classes does the necessary manipulations to the arguments and then passes to the original classes.

On similar lines, assume that the implementation and structure of BasketItem in Facade example needs to be changed. To handle such scenario, a new adapter class BasketItemAdapter is defined. It implements all the methods of the BasketItem and in each method makes necessary changes to the arguments and passes it to the new implementation as shown below.
== Example ==
<pre>
public Class BasketItemAdapter {
BasketItem newImplementation = new BasketItem();
void calculateCost(...) {
//make necessary modification
newImplementation.calculateCost(...);
}
}
</pre>

== Differences and similarities ==
* In both the Facade and Adapter pattern we have pre-existing classes.
* In the Facade, however, we do not have an interface we must design to, as we do in the Adapter pattern.
* We are not interested in polymorphic behavior in the Facade, while in the Adapter, We probably am.(There are times when we just need to design to a particular API and therefore must use an Adapter)
* In the case of the Facade pattern, the motivation is to simplify the interface. With the Adapter, while simpler is better,We are trying to design to an existing interface and cannot simplify things even if a simpler interface were otherwise possible.

Bottom line is a Facade simplifies an interface while an Adapter converts the interface into a pre-existing interface.

=Abstract Factory Pattern and Facade Pattern =

Abstract factory pattern provides a level of indirection that abstracts the creation of families of related or dependent objects without directly specifying their concrete classes. The “factory” object has the responsibility for providing creation services for the entire platform family. Clients never create platform objects directly, they ask the factory to do that for them.

This mechanism makes exchanging product families easy because the specific class of the factory object appears only once in the application - where it is instantiated. The application can wholesale replace the entire family of products simply by instantiating a different concrete instance of the abstract factory. Because the service provided by the factory object is so pervasive, it is routinely implemented as a Singleton. 

== Abstract Factory Example ==
[[File:Abstract.JPG|600px|center]]

The AbstractFactory defines the interface that all of the concrete factories will need to implement in order to product Products. ConcreteFactoryA and ConcreteFactoryB have both implemented this interface here, creating two seperate families of product. Meanwhile, AbstractProductA and AbstractProductB are interfaces for the different types of product. Each factory will create one of each of these AbstractProducts.

The Client deals with AbstractFactory, AbstractProductA and AbstractProductB. It doesn't know anything about the implementations. The actual implementation of AbstractFactory that the Client uses is determined at runtime.

As you can see, one of the main benefits of this pattern is that the client is totally decoupled from the concrete products. Also, new product families can be easily added into the system, by just adding in a new type of ConcreteFactory that implements AbstractFactory, and creating the specific Product implementations.

== Facade Pattern Example ==

[[File:Facade-wo.JPG|300px|thumb|center|Without a Facade, the client has to deal with the intricacies of the sub system.]]

[[File:Facade-w.JPG|300px|thumb|center|With a Facade, the complexities of sub system are unified into a single interface making it readily usable for the client.]]

Considering the example for the Facade pattern, Client requires access to Employee objects, but in order to get that, it first need to contact the Database and retrieve the Company objects. It then retrieves Division objects from them and finally gains access to Employee objects. So, we see that It uses four classes and has to deal with complex details of the sub system. With Facade, the Client is shielded from most of the classes. It uses the Database Facade to retrieve Employee objects directly.

== Differences and similarities between Facade and Abstract Factory patterns ==
<ul>
<li>Facade is a structural design pattern whereas Abstract Factory pattern is a creational design pattern.
<li>Both are similar in a way that both provide an interface. Abstract Factory , provides kind of a Facade for creating products that belongs to its own factories.
<li>With the Abstract Factory Pattern we just provide a common factory builder for many different builders for the same thing. This can be used whenever we need to provide an interface to a set of builders meant to be used with something in common (the product) without bothering on what are we going to build or which factory are we going to use. The Facade pattern instead is used to provide a simple interface to a lot of different operations that the client classes should not see.
</ul>

Thus we see that both patterns achieve quite different goals. The facade pattern is used when you want to hide an implementation or it is about changing interface of some class or set of classes. On the other hand Abstarct factory pattern is used when you want to hide the details on constructing instances. Provide an interface for creating families of related or dependent objects without specifying their concrete classes.

=Mediator Pattern and Facade Pattern=
In Unix, permission to access system resources is managed at three levels of granularity: world, group, and owner. A group is a collection of users intended to model some functional affiliation. Each user on the system can be a member of one or more groups, and each group can have zero or more users assigned to it. Next figure shows three users that are assigned to all three groups. If we were to model this in software, we could decide to have User objects coupled to Group objects, and Group objects coupled to User objects. Then when changes occur, both classes and all their instances would be affected. An alternate approach would be to introduce “an additional level of indirection” - take the mapping of users to groups and groups to users, and make it an abstraction unto itself. This offers several advantages: Users and Groups are decoupled from one another, many mappings can easily be maintained and manipulated simultaneously, and the mapping abstraction can be extended in the future by defining derived classes. 

Partitioning a system into many objects generally enhances reusability, but proliferating interconnections between those objects tend to reduce it again. The mediator object: encapsulates all interconnections, acts as the hub of communication, is responsible for controlling and coordinating the interactions of its clients, and promotes loose coupling by keeping objects from referring to each other explicitly.

[[File:Mediator__1.gif]]

Colleagues (or peers) are not coupled to one another. Each talks to the Mediator, which in turn knows and conducts the orchestration of the others. The “many to many” mapping between colleagues that would otherwise exist, has been “promoted to full object status”. This new abstraction provides a locus of indirection where additional leverage can be hosted.

Mediator is similar to Facade in that it abstracts functionality of existing classes. Mediator abstracts/centralizes arbitrary communication between colleague objects, it routinely “adds value”, and it is known/referenced by the colleague objects (i.e. it defines a multidirectional protocol). In contrast, Facade defines a simpler interface to a subsystem, it doesn’t add new functionality, and it is not known by the subsystem classes (i.e. it defines a unidirectional protocol where it makes requests of the subsystem classes but not vice versa).

=References=
<references/>

== Additional Reading ==

* [http://www.codeproject.com/Articles/15207/Design-Patterns-Command-Pattern Design Pattern: Command Pattern] at codeproject.com
* [http://java.dzone.com/articles/design-patterns-command Command Pattern in Java] at java.dzone.com
* [http://www.cs.mcgill.ca/~hv/classes/CS400/01.hchen/doc/command/command.html Basics of Command Pattern]
* [http://www.dofactory.com/Patterns/PatternCommand.aspx Command Pattern in C#] at dofactory.com

* [http://sourcemaking.com/design_patterns/command Behavorial Design Pattern - Command Pattern] at sourcemaking.com

* [http://perfectjpattern.sourceforge.net/dp-command.html GoF Command Pattern]

* McDonald,J. 2008. Design Patterns

CSC/ECE 517 Fall 2012/ch2b 2w42 aa

2012-11-20T01:02:17Z

Aasawa: /* References */

=Introduction =

==Facade Pattern==
Intent 
* Provide a unified interface to a set of interfaces in a subsystem. 
* Wrap a complicated subsystem with a simpler interface. 

Facade discusses encapsulating a complex subsystem within a single interface object. This reduces the learning curve necessary to successfully leverage the subsystem. It also promotes decoupling the subsystem from its potentially many clients. On the other hand, if the Facade is the only access point for the subsystem, it will limit the features and flexibility that “power users” may need. The Facade object should be a fairly simple advocate or facilitator. It should not become an all-knowing oracle or “god” object. 

== Adapter Pattern ==

Intent 
* Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn’t otherwise because of incompatible interfaces. 
* Wrap an existing class with a new interface. 
* Impedance match an old component to a new system. 

Convert the interface of a class into another interface clients expect. Adapter lets classes worktogether that couldn't otherwise because of incompatible interfaces.

==Abstract Factory Pattern==

Intent 
* Provide an interface for creating families of related or dependent objects without specifying their concrete classes. 
* A hierarchy that encapsulates: many possible “platforms”, and the construction of a suite of “products”. 
* The new operator considered harmful. 

If an application is to be portable, it needs to encapsulate platform dependencies. These “platforms” might include: windowing system, operating system, database, etc. Too often, this encapsulatation is not engineered in advance, and lots of #ifdef case statements with options for all currently supported platforms begin to procreate like rabbits throughout the code. 

==Mediator Pattern==
Intent 

* Define an object that encapsulates how a set of objects interact. Mediator promotes loose coupling by keeping objects from referring to each other explicitly, and it lets you vary their interaction independently.
* Design an intermediary to decouple many peers.
* Promote the many-to-many relationships between interacting peers to “full object status”.

=Facade Pattern =

==Non-Software examples<ref>[http://aspalliance.com/970_Facade_Design_Pattern.2 ASPAlliance - Facade Design Pattern - http://aspalliance.com/970_Facade_Design_Pattern.2]</ref>==
In most of the Pizza centers, orders will be given through phone calls with the customer interacting with the Customer service representative. In this case, consumers do not have access to the Billing system, Kitchen and delivery department. The customer service representative acts as an interface and interacts with each of the departments involved in the transaction and ensures that Pizzas are delivered to the consumer. Customer Service representative corresponds to the facade. Individual departments involved in the transaction correspond to Sub-systems.

==Software examples==
Web Service Facade Solution Architecture provides an example for Facade design pattern. In this architectural solution, instead of rewriting legacy applications or customizing those with middleware to connect to other applications one by one, this solution helps create a "facade" for the legacy application. Other applications are easily "plugged into" this facade. By modeling a legacy application into its basic functions of create, read, update, and delete and then exposing these functions as Web methods, the Web service facade solution allows other applications to access legacy data by making use of common Web services through standardized protocols. In this way, Facade decouples layers so that they do not depend on each other which can make it easier to develop, to use and to promote code re-use.

== C# Example ==
using System;
using System.Collections.Generic; 
namespace DesignPatterns.Facade
{
public class OrderFacade
{
//Places an Order and Returns an Order ID
public int placeOrder(int CustomerID, List<BasketItem> Products)
{
Order anOrder = new Order();
OrderLine anOrderLine = new OrderLine();
Address DespatchAddress = Address.getCustomerDespatchAddress(CustomerID);
int OrderId = anOrder.requestOrderID();
anOrder.createOrder(OrderId, DespatchAddress);
anOrderLine.addOrderLinesToOrder(OrderId, Products);
return OrderId;
}
} 
//order class
public class Order
{
public int requestOrderID()
{
//Creates and Returns a Unique Order ID
} 
public void createOrder(int OrderId, Address DespatchAddress)
{
}
} 
//OrderLine Class
public class OrderLine
{
public void addOrderLinesToOrder(int OrderId, List<BasketItem> Products)
{
}
} 
//Public Customer
public class Address
{
public static Address getCustomerDespatchAddress(int CustomerID)
{
return new Address();
}
//Address properties
} 
public class BasketItem
{
//BasketItem Properties
}
}

=Adapter Pattern and Facade Pattern =

Adapter functions as a wrapper or modifier of an existing class. It provides a different or translated view of that class. 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. Reuse has always been painful and elusive. One reason has been the tribulation of designing something new, while reusing something old. There is always something not quite right between the old and the new. It may be physical dimensions or misalignment. It may be timing or synchronization. It may be unfortunate assumptions or competing standards. It is like the problem of inserting a new three-prong electrical plug in an old two-prong wall outlet – some kind of adapter or intermediary is necessary. 

Adapter is about creating an intermediary abstraction that translates, or maps, the old component to the new system. Clients call methods on the Adapter object which redirects them into calls to the legacy component. This strategy can be implemented either with inheritance or with aggregation. 

== Adapter Pattern Example ==
<pre>
interface Shape {
void draw(...);
}

Class LegacyLine {
void draw(..) { }
}

Class LegacyRectangle {
void draw(..) { }
}

Class Line implements Shape {
adapter = new LegacyLine();
void draw(...) {adapter.draw(...)}
}

Class Rectangle implements Shape {
adapter = new LegacyRectangle();
void draw(...) {adapter.draw(...)}
}
</pre>

In the example provided for the Facade pattern, the method placeOrder() uses the methods exposed by many other classes such as Order, OrderLine, Address etc to provide a high level view for the callers. The callers need not worry about the complexities in handling the sub-system. The users of the Class OrderFacade just invoke the method placeOrder() with the necessary arguments and rest of the process is taken care by placeOrder(). As can be seen in this case, a new method (placeOrder) was defined which has the logic and the necessary steps to handle all the sub-systems to create an order, create an id for the order, create a dispatch address etc.

In the example provided for the Adapter pattern, no new methods are defined. The existing method draw of LegacyRectangle is wrapped in a adapter class Rectangle. The methods in adapter classes does the necessary manipulations to the arguments and then passes to the original classes.

On similar lines, assume that the implementation and structure of BasketItem in Facade example needs to be changed. To handle such scenario, a new adapter class BasketItemAdapter is defined. It implements all the methods of the BasketItem and in each method makes necessary changes to the arguments and passes it to the new implementation as shown below.
== Example ==
<pre>
public Class BasketItemAdapter {
BasketItem newImplementation = new BasketItem();
void calculateCost(...) {
//make necessary modification
newImplementation.calculateCost(...);
}
}
</pre>

== Differences and similarities ==
* In both the Facade and Adapter pattern we have pre-existing classes.
* In the Facade, however, we do not have an interface we must design to, as we do in the Adapter pattern.
* We are not interested in polymorphic behavior in the Facade, while in the Adapter, We probably am.(There are times when we just need to design to a particular API and therefore must use an Adapter)
* In the case of the Facade pattern, the motivation is to simplify the interface. With the Adapter, while simpler is better,We are trying to design to an existing interface and cannot simplify things even if a simpler interface were otherwise possible.

Bottom line is a Facade simplifies an interface while an Adapter converts the interface into a pre-existing interface.

=Abstract Factory Pattern and Facade Pattern =

Abstract factory pattern provides a level of indirection that abstracts the creation of families of related or dependent objects without directly specifying their concrete classes. The “factory” object has the responsibility for providing creation services for the entire platform family. Clients never create platform objects directly, they ask the factory to do that for them.

This mechanism makes exchanging product families easy because the specific class of the factory object appears only once in the application - where it is instantiated. The application can wholesale replace the entire family of products simply by instantiating a different concrete instance of the abstract factory. Because the service provided by the factory object is so pervasive, it is routinely implemented as a Singleton. 

== Abstract Factory Example ==
[[File:Abstract.JPG|600px|center]]

The AbstractFactory defines the interface that all of the concrete factories will need to implement in order to product Products. ConcreteFactoryA and ConcreteFactoryB have both implemented this interface here, creating two seperate families of product. Meanwhile, AbstractProductA and AbstractProductB are interfaces for the different types of product. Each factory will create one of each of these AbstractProducts.

The Client deals with AbstractFactory, AbstractProductA and AbstractProductB. It doesn't know anything about the implementations. The actual implementation of AbstractFactory that the Client uses is determined at runtime.

As you can see, one of the main benefits of this pattern is that the client is totally decoupled from the concrete products. Also, new product families can be easily added into the system, by just adding in a new type of ConcreteFactory that implements AbstractFactory, and creating the specific Product implementations.

== Facade Pattern Example ==

[[File:Facade-wo.JPG|300px|thumb|center|Without a Facade, the client has to deal with the intricacies of the sub system.]]

[[File:Facade-w.JPG|300px|thumb|center|With a Facade, the complexities of sub system are unified into a single interface making it readily usable for the client.]]

Considering the example for the Facade pattern, Client requires access to Employee objects, but in order to get that, it first need to contact the Database and retrieve the Company objects. It then retrieves Division objects from them and finally gains access to Employee objects. So, we see that It uses four classes and has to deal with complex details of the sub system. With Facade, the Client is shielded from most of the classes. It uses the Database Facade to retrieve Employee objects directly.

== Differences and similarities between Facade and Abstract Factory patterns ==
<ul>
<li>Facade is a structural design pattern whereas Abstract Factory pattern is a creational design pattern.
<li>Both are similar in a way that both provide an interface. Abstract Factory , provides kind of a Facade for creating products that belongs to its own factories.
<li>With the Abstract Factory Pattern we just provide a common factory builder for many different builders for the same thing. This can be used whenever we need to provide an interface to a set of builders meant to be used with something in common (the product) without bothering on what are we going to build or which factory are we going to use. The Facade pattern instead is used to provide a simple interface to a lot of different operations that the client classes should not see.
</ul>

Thus we see that both patterns achieve quite different goals. The facade pattern is used when you want to hide an implementation or it is about changing interface of some class or set of classes. On the other hand Abstarct factory pattern is used when you want to hide the details on constructing instances. Provide an interface for creating families of related or dependent objects without specifying their concrete classes.

=Mediator Pattern and Facade Pattern=
In Unix, permission to access system resources is managed at three levels of granularity: world, group, and owner. A group is a collection of users intended to model some functional affiliation. Each user on the system can be a member of one or more groups, and each group can have zero or more users assigned to it. Next figure shows three users that are assigned to all three groups. If we were to model this in software, we could decide to have User objects coupled to Group objects, and Group objects coupled to User objects. Then when changes occur, both classes and all their instances would be affected. An alternate approach would be to introduce “an additional level of indirection” - take the mapping of users to groups and groups to users, and make it an abstraction unto itself. This offers several advantages: Users and Groups are decoupled from one another, many mappings can easily be maintained and manipulated simultaneously, and the mapping abstraction can be extended in the future by defining derived classes. 

Partitioning a system into many objects generally enhances reusability, but proliferating interconnections between those objects tend to reduce it again. The mediator object: encapsulates all interconnections, acts as the hub of communication, is responsible for controlling and coordinating the interactions of its clients, and promotes loose coupling by keeping objects from referring to each other explicitly.

[[File:Mediator__1.gif]]

Colleagues (or peers) are not coupled to one another. Each talks to the Mediator, which in turn knows and conducts the orchestration of the others. The “many to many” mapping between colleagues that would otherwise exist, has been “promoted to full object status”. This new abstraction provides a locus of indirection where additional leverage can be hosted.

Mediator is similar to Facade in that it abstracts functionality of existing classes. Mediator abstracts/centralizes arbitrary communication between colleague objects, it routinely “adds value”, and it is known/referenced by the colleague objects (i.e. it defines a multidirectional protocol). In contrast, Facade defines a simpler interface to a subsystem, it doesn’t add new functionality, and it is not known by the subsystem classes (i.e. it defines a unidirectional protocol where it makes requests of the subsystem classes but not vice versa).

=References=
<references/>

CSC/ECE 517 Fall 2012/ch2b 2w42 aa

2012-11-20T01:00:51Z

Aasawa: /* Non-Software examples */

=Introduction =

==Facade Pattern==
Intent 
* Provide a unified interface to a set of interfaces in a subsystem. 
* Wrap a complicated subsystem with a simpler interface. 

Facade discusses encapsulating a complex subsystem within a single interface object. This reduces the learning curve necessary to successfully leverage the subsystem. It also promotes decoupling the subsystem from its potentially many clients. On the other hand, if the Facade is the only access point for the subsystem, it will limit the features and flexibility that “power users” may need. The Facade object should be a fairly simple advocate or facilitator. It should not become an all-knowing oracle or “god” object. 

== Adapter Pattern ==

Intent 
* Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn’t otherwise because of incompatible interfaces. 
* Wrap an existing class with a new interface. 
* Impedance match an old component to a new system. 

Convert the interface of a class into another interface clients expect. Adapter lets classes worktogether that couldn't otherwise because of incompatible interfaces.

==Abstract Factory Pattern==

Intent 
* Provide an interface for creating families of related or dependent objects without specifying their concrete classes. 
* A hierarchy that encapsulates: many possible “platforms”, and the construction of a suite of “products”. 
* The new operator considered harmful. 

If an application is to be portable, it needs to encapsulate platform dependencies. These “platforms” might include: windowing system, operating system, database, etc. Too often, this encapsulatation is not engineered in advance, and lots of #ifdef case statements with options for all currently supported platforms begin to procreate like rabbits throughout the code. 

==Mediator Pattern==
Intent 

* Define an object that encapsulates how a set of objects interact. Mediator promotes loose coupling by keeping objects from referring to each other explicitly, and it lets you vary their interaction independently.
* Design an intermediary to decouple many peers.
* Promote the many-to-many relationships between interacting peers to “full object status”.

=Facade Pattern =

==Non-Software examples<ref>[http://aspalliance.com/970_Facade_Design_Pattern.2 ASPAlliance - Facade Design Pattern - http://aspalliance.com/970_Facade_Design_Pattern.2]</ref>==
In most of the Pizza centers, orders will be given through phone calls with the customer interacting with the Customer service representative. In this case, consumers do not have access to the Billing system, Kitchen and delivery department. The customer service representative acts as an interface and interacts with each of the departments involved in the transaction and ensures that Pizzas are delivered to the consumer. Customer Service representative corresponds to the facade. Individual departments involved in the transaction correspond to Sub-systems.

==Software examples==
Web Service Facade Solution Architecture provides an example for Facade design pattern. In this architectural solution, instead of rewriting legacy applications or customizing those with middleware to connect to other applications one by one, this solution helps create a "facade" for the legacy application. Other applications are easily "plugged into" this facade. By modeling a legacy application into its basic functions of create, read, update, and delete and then exposing these functions as Web methods, the Web service facade solution allows other applications to access legacy data by making use of common Web services through standardized protocols. In this way, Facade decouples layers so that they do not depend on each other which can make it easier to develop, to use and to promote code re-use.

== C# Example ==
using System;
using System.Collections.Generic; 
namespace DesignPatterns.Facade
{
public class OrderFacade
{
//Places an Order and Returns an Order ID
public int placeOrder(int CustomerID, List<BasketItem> Products)
{
Order anOrder = new Order();
OrderLine anOrderLine = new OrderLine();
Address DespatchAddress = Address.getCustomerDespatchAddress(CustomerID);
int OrderId = anOrder.requestOrderID();
anOrder.createOrder(OrderId, DespatchAddress);
anOrderLine.addOrderLinesToOrder(OrderId, Products);
return OrderId;
}
} 
//order class
public class Order
{
public int requestOrderID()
{
//Creates and Returns a Unique Order ID
} 
public void createOrder(int OrderId, Address DespatchAddress)
{
}
} 
//OrderLine Class
public class OrderLine
{
public void addOrderLinesToOrder(int OrderId, List<BasketItem> Products)
{
}
} 
//Public Customer
public class Address
{
public static Address getCustomerDespatchAddress(int CustomerID)
{
return new Address();
}
//Address properties
} 
public class BasketItem
{
//BasketItem Properties
}
}

=Adapter Pattern and Facade Pattern =

Adapter functions as a wrapper or modifier of an existing class. It provides a different or translated view of that class. 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. Reuse has always been painful and elusive. One reason has been the tribulation of designing something new, while reusing something old. There is always something not quite right between the old and the new. It may be physical dimensions or misalignment. It may be timing or synchronization. It may be unfortunate assumptions or competing standards. It is like the problem of inserting a new three-prong electrical plug in an old two-prong wall outlet – some kind of adapter or intermediary is necessary. 

Adapter is about creating an intermediary abstraction that translates, or maps, the old component to the new system. Clients call methods on the Adapter object which redirects them into calls to the legacy component. This strategy can be implemented either with inheritance or with aggregation. 

== Adapter Pattern Example ==
<pre>
interface Shape {
void draw(...);
}

Class LegacyLine {
void draw(..) { }
}

Class LegacyRectangle {
void draw(..) { }
}

Class Line implements Shape {
adapter = new LegacyLine();
void draw(...) {adapter.draw(...)}
}

Class Rectangle implements Shape {
adapter = new LegacyRectangle();
void draw(...) {adapter.draw(...)}
}
</pre>

In the example provided for the Facade pattern, the method placeOrder() uses the methods exposed by many other classes such as Order, OrderLine, Address etc to provide a high level view for the callers. The callers need not worry about the complexities in handling the sub-system. The users of the Class OrderFacade just invoke the method placeOrder() with the necessary arguments and rest of the process is taken care by placeOrder(). As can be seen in this case, a new method (placeOrder) was defined which has the logic and the necessary steps to handle all the sub-systems to create an order, create an id for the order, create a dispatch address etc.

In the example provided for the Adapter pattern, no new methods are defined. The existing method draw of LegacyRectangle is wrapped in a adapter class Rectangle. The methods in adapter classes does the necessary manipulations to the arguments and then passes to the original classes.

On similar lines, assume that the implementation and structure of BasketItem in Facade example needs to be changed. To handle such scenario, a new adapter class BasketItemAdapter is defined. It implements all the methods of the BasketItem and in each method makes necessary changes to the arguments and passes it to the new implementation as shown below.
== Example ==
<pre>
public Class BasketItemAdapter {
BasketItem newImplementation = new BasketItem();
void calculateCost(...) {
//make necessary modification
newImplementation.calculateCost(...);
}
}
</pre>

== Differences and similarities ==
* In both the Facade and Adapter pattern we have pre-existing classes.
* In the Facade, however, we do not have an interface we must design to, as we do in the Adapter pattern.
* We are not interested in polymorphic behavior in the Facade, while in the Adapter, We probably am.(There are times when we just need to design to a particular API and therefore must use an Adapter)
* In the case of the Facade pattern, the motivation is to simplify the interface. With the Adapter, while simpler is better,We are trying to design to an existing interface and cannot simplify things even if a simpler interface were otherwise possible.

Bottom line is a Facade simplifies an interface while an Adapter converts the interface into a pre-existing interface.

=Abstract Factory Pattern and Facade Pattern =

Abstract factory pattern provides a level of indirection that abstracts the creation of families of related or dependent objects without directly specifying their concrete classes. The “factory” object has the responsibility for providing creation services for the entire platform family. Clients never create platform objects directly, they ask the factory to do that for them.

This mechanism makes exchanging product families easy because the specific class of the factory object appears only once in the application - where it is instantiated. The application can wholesale replace the entire family of products simply by instantiating a different concrete instance of the abstract factory. Because the service provided by the factory object is so pervasive, it is routinely implemented as a Singleton. 

== Abstract Factory Example ==
[[File:Abstract.JPG|600px|center]]

The AbstractFactory defines the interface that all of the concrete factories will need to implement in order to product Products. ConcreteFactoryA and ConcreteFactoryB have both implemented this interface here, creating two seperate families of product. Meanwhile, AbstractProductA and AbstractProductB are interfaces for the different types of product. Each factory will create one of each of these AbstractProducts.

The Client deals with AbstractFactory, AbstractProductA and AbstractProductB. It doesn't know anything about the implementations. The actual implementation of AbstractFactory that the Client uses is determined at runtime.

As you can see, one of the main benefits of this pattern is that the client is totally decoupled from the concrete products. Also, new product families can be easily added into the system, by just adding in a new type of ConcreteFactory that implements AbstractFactory, and creating the specific Product implementations.

== Facade Pattern Example ==

[[File:Facade-wo.JPG|300px|thumb|center|Without a Facade, the client has to deal with the intricacies of the sub system.]]

[[File:Facade-w.JPG|300px|thumb|center|With a Facade, the complexities of sub system are unified into a single interface making it readily usable for the client.]]

Considering the example for the Facade pattern, Client requires access to Employee objects, but in order to get that, it first need to contact the Database and retrieve the Company objects. It then retrieves Division objects from them and finally gains access to Employee objects. So, we see that It uses four classes and has to deal with complex details of the sub system. With Facade, the Client is shielded from most of the classes. It uses the Database Facade to retrieve Employee objects directly.

== Differences and similarities between Facade and Abstract Factory patterns ==
<ul>
<li>Facade is a structural design pattern whereas Abstract Factory pattern is a creational design pattern.
<li>Both are similar in a way that both provide an interface. Abstract Factory , provides kind of a Facade for creating products that belongs to its own factories.
<li>With the Abstract Factory Pattern we just provide a common factory builder for many different builders for the same thing. This can be used whenever we need to provide an interface to a set of builders meant to be used with something in common (the product) without bothering on what are we going to build or which factory are we going to use. The Facade pattern instead is used to provide a simple interface to a lot of different operations that the client classes should not see.
</ul>

Thus we see that both patterns achieve quite different goals. The facade pattern is used when you want to hide an implementation or it is about changing interface of some class or set of classes. On the other hand Abstarct factory pattern is used when you want to hide the details on constructing instances. Provide an interface for creating families of related or dependent objects without specifying their concrete classes.

=Mediator Pattern and Facade Pattern=
In Unix, permission to access system resources is managed at three levels of granularity: world, group, and owner. A group is a collection of users intended to model some functional affiliation. Each user on the system can be a member of one or more groups, and each group can have zero or more users assigned to it. Next figure shows three users that are assigned to all three groups. If we were to model this in software, we could decide to have User objects coupled to Group objects, and Group objects coupled to User objects. Then when changes occur, both classes and all their instances would be affected. An alternate approach would be to introduce “an additional level of indirection” - take the mapping of users to groups and groups to users, and make it an abstraction unto itself. This offers several advantages: Users and Groups are decoupled from one another, many mappings can easily be maintained and manipulated simultaneously, and the mapping abstraction can be extended in the future by defining derived classes. 

Partitioning a system into many objects generally enhances reusability, but proliferating interconnections between those objects tend to reduce it again. The mediator object: encapsulates all interconnections, acts as the hub of communication, is responsible for controlling and coordinating the interactions of its clients, and promotes loose coupling by keeping objects from referring to each other explicitly.

[[File:Mediator__1.gif]]

Colleagues (or peers) are not coupled to one another. Each talks to the Mediator, which in turn knows and conducts the orchestration of the others. The “many to many” mapping between colleagues that would otherwise exist, has been “promoted to full object status”. This new abstraction provides a locus of indirection where additional leverage can be hosted.

Mediator is similar to Facade in that it abstracts functionality of existing classes. Mediator abstracts/centralizes arbitrary communication between colleague objects, it routinely “adds value”, and it is known/referenced by the colleague objects (i.e. it defines a multidirectional protocol). In contrast, Facade defines a simpler interface to a subsystem, it doesn’t add new functionality, and it is not known by the subsystem classes (i.e. it defines a unidirectional protocol where it makes requests of the subsystem classes but not vice versa).

=References=

CSC/ECE 517 Fall 2012/ch2b 2w42 aa

2012-11-20T00:54:57Z

Aasawa: /* Abstract Factory Pattern and Facade Pattern */

=Introduction =

==Facade Pattern==
Intent 
* Provide a unified interface to a set of interfaces in a subsystem. 
* Wrap a complicated subsystem with a simpler interface. 

Facade discusses encapsulating a complex subsystem within a single interface object. This reduces the learning curve necessary to successfully leverage the subsystem. It also promotes decoupling the subsystem from its potentially many clients. On the other hand, if the Facade is the only access point for the subsystem, it will limit the features and flexibility that “power users” may need. The Facade object should be a fairly simple advocate or facilitator. It should not become an all-knowing oracle or “god” object. 

== Adapter Pattern ==

Intent 
* Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn’t otherwise because of incompatible interfaces. 
* Wrap an existing class with a new interface. 
* Impedance match an old component to a new system. 

Convert the interface of a class into another interface clients expect. Adapter lets classes worktogether that couldn't otherwise because of incompatible interfaces.

==Abstract Factory Pattern==

Intent 
* Provide an interface for creating families of related or dependent objects without specifying their concrete classes. 
* A hierarchy that encapsulates: many possible “platforms”, and the construction of a suite of “products”. 
* The new operator considered harmful. 

If an application is to be portable, it needs to encapsulate platform dependencies. These “platforms” might include: windowing system, operating system, database, etc. Too often, this encapsulatation is not engineered in advance, and lots of #ifdef case statements with options for all currently supported platforms begin to procreate like rabbits throughout the code. 

==Mediator Pattern==
Intent 

* Define an object that encapsulates how a set of objects interact. Mediator promotes loose coupling by keeping objects from referring to each other explicitly, and it lets you vary their interaction independently.
* Design an intermediary to decouple many peers.
* Promote the many-to-many relationships between interacting peers to “full object status”.

=Facade Pattern =

==Non-Software examples==
In most of the Pizza centers, orders will be given through phone calls with the customer interacting with the Customer service representative. In this case, consumers do not have access to the Billing system, Kitchen and delivery department. The customer service representative acts as an interface and interacts with each of the departments involved in the transaction and ensures that Pizzas are delivered to the consumer. Customer Service representative corresponds to the facade. Individual departments involved in the transaction correspond to Sub-systems.

==Software examples==
Web Service Facade Solution Architecture provides an example for Facade design pattern. In this architectural solution, instead of rewriting legacy applications or customizing those with middleware to connect to other applications one by one, this solution helps create a "facade" for the legacy application. Other applications are easily "plugged into" this facade. By modeling a legacy application into its basic functions of create, read, update, and delete and then exposing these functions as Web methods, the Web service facade solution allows other applications to access legacy data by making use of common Web services through standardized protocols. In this way, Facade decouples layers so that they do not depend on each other which can make it easier to develop, to use and to promote code re-use.

== C# Example ==
using System;
using System.Collections.Generic; 
namespace DesignPatterns.Facade
{
public class OrderFacade
{
//Places an Order and Returns an Order ID
public int placeOrder(int CustomerID, List<BasketItem> Products)
{
Order anOrder = new Order();
OrderLine anOrderLine = new OrderLine();
Address DespatchAddress = Address.getCustomerDespatchAddress(CustomerID);
int OrderId = anOrder.requestOrderID();
anOrder.createOrder(OrderId, DespatchAddress);
anOrderLine.addOrderLinesToOrder(OrderId, Products);
return OrderId;
}
} 
//order class
public class Order
{
public int requestOrderID()
{
//Creates and Returns a Unique Order ID
} 
public void createOrder(int OrderId, Address DespatchAddress)
{
}
} 
//OrderLine Class
public class OrderLine
{
public void addOrderLinesToOrder(int OrderId, List<BasketItem> Products)
{
}
} 
//Public Customer
public class Address
{
public static Address getCustomerDespatchAddress(int CustomerID)
{
return new Address();
}
//Address properties
} 
public class BasketItem
{
//BasketItem Properties
}
}

=Adapter Pattern and Facade Pattern =

Adapter functions as a wrapper or modifier of an existing class. It provides a different or translated view of that class. 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. Reuse has always been painful and elusive. One reason has been the tribulation of designing something new, while reusing something old. There is always something not quite right between the old and the new. It may be physical dimensions or misalignment. It may be timing or synchronization. It may be unfortunate assumptions or competing standards. It is like the problem of inserting a new three-prong electrical plug in an old two-prong wall outlet – some kind of adapter or intermediary is necessary. 

Adapter is about creating an intermediary abstraction that translates, or maps, the old component to the new system. Clients call methods on the Adapter object which redirects them into calls to the legacy component. This strategy can be implemented either with inheritance or with aggregation. 

== Adapter Pattern Example ==
<pre>
interface Shape {
void draw(...);
}

Class LegacyLine {
void draw(..) { }
}

Class LegacyRectangle {
void draw(..) { }
}

Class Line implements Shape {
adapter = new LegacyLine();
void draw(...) {adapter.draw(...)}
}

Class Rectangle implements Shape {
adapter = new LegacyRectangle();
void draw(...) {adapter.draw(...)}
}
</pre>

In the example provided for the Facade pattern, the method placeOrder() uses the methods exposed by many other classes such as Order, OrderLine, Address etc to provide a high level view for the callers. The callers need not worry about the complexities in handling the sub-system. The users of the Class OrderFacade just invoke the method placeOrder() with the necessary arguments and rest of the process is taken care by placeOrder(). As can be seen in this case, a new method (placeOrder) was defined which has the logic and the necessary steps to handle all the sub-systems to create an order, create an id for the order, create a dispatch address etc.

In the example provided for the Adapter pattern, no new methods are defined. The existing method draw of LegacyRectangle is wrapped in a adapter class Rectangle. The methods in adapter classes does the necessary manipulations to the arguments and then passes to the original classes.

On similar lines, assume that the implementation and structure of BasketItem in Facade example needs to be changed. To handle such scenario, a new adapter class BasketItemAdapter is defined. It implements all the methods of the BasketItem and in each method makes necessary changes to the arguments and passes it to the new implementation as shown below.
== Example ==
<pre>
public Class BasketItemAdapter {
BasketItem newImplementation = new BasketItem();
void calculateCost(...) {
//make necessary modification
newImplementation.calculateCost(...);
}
}
</pre>

== Differences and similarities ==
* In both the Facade and Adapter pattern we have pre-existing classes.
* In the Facade, however, we do not have an interface we must design to, as we do in the Adapter pattern.
* We are not interested in polymorphic behavior in the Facade, while in the Adapter, We probably am.(There are times when we just need to design to a particular API and therefore must use an Adapter)
* In the case of the Facade pattern, the motivation is to simplify the interface. With the Adapter, while simpler is better,We are trying to design to an existing interface and cannot simplify things even if a simpler interface were otherwise possible.

Bottom line is a Facade simplifies an interface while an Adapter converts the interface into a pre-existing interface.

=Abstract Factory Pattern and Facade Pattern =

Abstract factory pattern provides a level of indirection that abstracts the creation of families of related or dependent objects without directly specifying their concrete classes. The “factory” object has the responsibility for providing creation services for the entire platform family. Clients never create platform objects directly, they ask the factory to do that for them.

This mechanism makes exchanging product families easy because the specific class of the factory object appears only once in the application - where it is instantiated. The application can wholesale replace the entire family of products simply by instantiating a different concrete instance of the abstract factory. Because the service provided by the factory object is so pervasive, it is routinely implemented as a Singleton. 

== Abstract Factory Example ==
[[File:Abstract.JPG|600px|center]]

The AbstractFactory defines the interface that all of the concrete factories will need to implement in order to product Products. ConcreteFactoryA and ConcreteFactoryB have both implemented this interface here, creating two seperate families of product. Meanwhile, AbstractProductA and AbstractProductB are interfaces for the different types of product. Each factory will create one of each of these AbstractProducts.

The Client deals with AbstractFactory, AbstractProductA and AbstractProductB. It doesn't know anything about the implementations. The actual implementation of AbstractFactory that the Client uses is determined at runtime.

As you can see, one of the main benefits of this pattern is that the client is totally decoupled from the concrete products. Also, new product families can be easily added into the system, by just adding in a new type of ConcreteFactory that implements AbstractFactory, and creating the specific Product implementations.

== Facade Pattern Example ==

[[File:Facade-wo.JPG|300px|thumb|center|Without a Facade, the client has to deal with the intricacies of the sub system.]]

[[File:Facade-w.JPG|300px|thumb|center|With a Facade, the complexities of sub system are unified into a single interface making it readily usable for the client.]]

Considering the example for the Facade pattern, Client requires access to Employee objects, but in order to get that, it first need to contact the Database and retrieve the Company objects. It then retrieves Division objects from them and finally gains access to Employee objects. So, we see that It uses four classes and has to deal with complex details of the sub system. With Facade, the Client is shielded from most of the classes. It uses the Database Facade to retrieve Employee objects directly.

== Differences and similarities between Facade and Abstract Factory patterns ==
<ul>
<li>Facade is a structural design pattern whereas Abstract Factory pattern is a creational design pattern.
<li>Both are similar in a way that both provide an interface. Abstract Factory , provides kind of a Facade for creating products that belongs to its own factories.
<li>With the Abstract Factory Pattern we just provide a common factory builder for many different builders for the same thing. This can be used whenever we need to provide an interface to a set of builders meant to be used with something in common (the product) without bothering on what are we going to build or which factory are we going to use. The Facade pattern instead is used to provide a simple interface to a lot of different operations that the client classes should not see.
</ul>

Thus we see that both patterns achieve quite different goals. The facade pattern is used when you want to hide an implementation or it is about changing interface of some class or set of classes. On the other hand Abstarct factory pattern is used when you want to hide the details on constructing instances. Provide an interface for creating families of related or dependent objects without specifying their concrete classes.

=Mediator Pattern and Facade Pattern=
In Unix, permission to access system resources is managed at three levels of granularity: world, group, and owner. A group is a collection of users intended to model some functional affiliation. Each user on the system can be a member of one or more groups, and each group can have zero or more users assigned to it. Next figure shows three users that are assigned to all three groups. If we were to model this in software, we could decide to have User objects coupled to Group objects, and Group objects coupled to User objects. Then when changes occur, both classes and all their instances would be affected. An alternate approach would be to introduce “an additional level of indirection” - take the mapping of users to groups and groups to users, and make it an abstraction unto itself. This offers several advantages: Users and Groups are decoupled from one another, many mappings can easily be maintained and manipulated simultaneously, and the mapping abstraction can be extended in the future by defining derived classes. 

Partitioning a system into many objects generally enhances reusability, but proliferating interconnections between those objects tend to reduce it again. The mediator object: encapsulates all interconnections, acts as the hub of communication, is responsible for controlling and coordinating the interactions of its clients, and promotes loose coupling by keeping objects from referring to each other explicitly.

[[File:Mediator__1.gif]]

Colleagues (or peers) are not coupled to one another. Each talks to the Mediator, which in turn knows and conducts the orchestration of the others. The “many to many” mapping between colleagues that would otherwise exist, has been “promoted to full object status”. This new abstraction provides a locus of indirection where additional leverage can be hosted.

Mediator is similar to Facade in that it abstracts functionality of existing classes. Mediator abstracts/centralizes arbitrary communication between colleague objects, it routinely “adds value”, and it is known/referenced by the colleague objects (i.e. it defines a multidirectional protocol). In contrast, Facade defines a simpler interface to a subsystem, it doesn’t add new functionality, and it is not known by the subsystem classes (i.e. it defines a unidirectional protocol where it makes requests of the subsystem classes but not vice versa).

=References=

CSC/ECE 517 Fall 2012/ch2b 2w42 aa

2012-11-20T00:54:18Z

Aasawa: /* Abstract Factory Pattern and Facade Pattern */

=Introduction =

==Facade Pattern==
Intent 
* Provide a unified interface to a set of interfaces in a subsystem. 
* Wrap a complicated subsystem with a simpler interface. 

Facade discusses encapsulating a complex subsystem within a single interface object. This reduces the learning curve necessary to successfully leverage the subsystem. It also promotes decoupling the subsystem from its potentially many clients. On the other hand, if the Facade is the only access point for the subsystem, it will limit the features and flexibility that “power users” may need. The Facade object should be a fairly simple advocate or facilitator. It should not become an all-knowing oracle or “god” object. 

== Adapter Pattern ==

Intent 
* Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn’t otherwise because of incompatible interfaces. 
* Wrap an existing class with a new interface. 
* Impedance match an old component to a new system. 

Convert the interface of a class into another interface clients expect. Adapter lets classes worktogether that couldn't otherwise because of incompatible interfaces.

==Abstract Factory Pattern==

Intent 
* Provide an interface for creating families of related or dependent objects without specifying their concrete classes. 
* A hierarchy that encapsulates: many possible “platforms”, and the construction of a suite of “products”. 
* The new operator considered harmful. 

If an application is to be portable, it needs to encapsulate platform dependencies. These “platforms” might include: windowing system, operating system, database, etc. Too often, this encapsulatation is not engineered in advance, and lots of #ifdef case statements with options for all currently supported platforms begin to procreate like rabbits throughout the code. 

==Mediator Pattern==
Intent 

* Define an object that encapsulates how a set of objects interact. Mediator promotes loose coupling by keeping objects from referring to each other explicitly, and it lets you vary their interaction independently.
* Design an intermediary to decouple many peers.
* Promote the many-to-many relationships between interacting peers to “full object status”.

=Facade Pattern =

==Non-Software examples==
In most of the Pizza centers, orders will be given through phone calls with the customer interacting with the Customer service representative. In this case, consumers do not have access to the Billing system, Kitchen and delivery department. The customer service representative acts as an interface and interacts with each of the departments involved in the transaction and ensures that Pizzas are delivered to the consumer. Customer Service representative corresponds to the facade. Individual departments involved in the transaction correspond to Sub-systems.

==Software examples==
Web Service Facade Solution Architecture provides an example for Facade design pattern. In this architectural solution, instead of rewriting legacy applications or customizing those with middleware to connect to other applications one by one, this solution helps create a "facade" for the legacy application. Other applications are easily "plugged into" this facade. By modeling a legacy application into its basic functions of create, read, update, and delete and then exposing these functions as Web methods, the Web service facade solution allows other applications to access legacy data by making use of common Web services through standardized protocols. In this way, Facade decouples layers so that they do not depend on each other which can make it easier to develop, to use and to promote code re-use.

== C# Example ==
using System;
using System.Collections.Generic; 
namespace DesignPatterns.Facade
{
public class OrderFacade
{
//Places an Order and Returns an Order ID
public int placeOrder(int CustomerID, List<BasketItem> Products)
{
Order anOrder = new Order();
OrderLine anOrderLine = new OrderLine();
Address DespatchAddress = Address.getCustomerDespatchAddress(CustomerID);
int OrderId = anOrder.requestOrderID();
anOrder.createOrder(OrderId, DespatchAddress);
anOrderLine.addOrderLinesToOrder(OrderId, Products);
return OrderId;
}
} 
//order class
public class Order
{
public int requestOrderID()
{
//Creates and Returns a Unique Order ID
} 
public void createOrder(int OrderId, Address DespatchAddress)
{
}
} 
//OrderLine Class
public class OrderLine
{
public void addOrderLinesToOrder(int OrderId, List<BasketItem> Products)
{
}
} 
//Public Customer
public class Address
{
public static Address getCustomerDespatchAddress(int CustomerID)
{
return new Address();
}
//Address properties
} 
public class BasketItem
{
//BasketItem Properties
}
}

=Adapter Pattern and Facade Pattern =

Adapter functions as a wrapper or modifier of an existing class. It provides a different or translated view of that class. 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. Reuse has always been painful and elusive. One reason has been the tribulation of designing something new, while reusing something old. There is always something not quite right between the old and the new. It may be physical dimensions or misalignment. It may be timing or synchronization. It may be unfortunate assumptions or competing standards. It is like the problem of inserting a new three-prong electrical plug in an old two-prong wall outlet – some kind of adapter or intermediary is necessary. 

Adapter is about creating an intermediary abstraction that translates, or maps, the old component to the new system. Clients call methods on the Adapter object which redirects them into calls to the legacy component. This strategy can be implemented either with inheritance or with aggregation. 

== Adapter Pattern Example ==
<pre>
interface Shape {
void draw(...);
}

Class LegacyLine {
void draw(..) { }
}

Class LegacyRectangle {
void draw(..) { }
}

Class Line implements Shape {
adapter = new LegacyLine();
void draw(...) {adapter.draw(...)}
}

Class Rectangle implements Shape {
adapter = new LegacyRectangle();
void draw(...) {adapter.draw(...)}
}
</pre>

In the example provided for the Facade pattern, the method placeOrder() uses the methods exposed by many other classes such as Order, OrderLine, Address etc to provide a high level view for the callers. The callers need not worry about the complexities in handling the sub-system. The users of the Class OrderFacade just invoke the method placeOrder() with the necessary arguments and rest of the process is taken care by placeOrder(). As can be seen in this case, a new method (placeOrder) was defined which has the logic and the necessary steps to handle all the sub-systems to create an order, create an id for the order, create a dispatch address etc.

In the example provided for the Adapter pattern, no new methods are defined. The existing method draw of LegacyRectangle is wrapped in a adapter class Rectangle. The methods in adapter classes does the necessary manipulations to the arguments and then passes to the original classes.

On similar lines, assume that the implementation and structure of BasketItem in Facade example needs to be changed. To handle such scenario, a new adapter class BasketItemAdapter is defined. It implements all the methods of the BasketItem and in each method makes necessary changes to the arguments and passes it to the new implementation as shown below.
== Example ==
<pre>
public Class BasketItemAdapter {
BasketItem newImplementation = new BasketItem();
void calculateCost(...) {
//make necessary modification
newImplementation.calculateCost(...);
}
}
</pre>

== Differences and similarities ==
* In both the Facade and Adapter pattern we have pre-existing classes.
* In the Facade, however, we do not have an interface we must design to, as we do in the Adapter pattern.
* We are not interested in polymorphic behavior in the Facade, while in the Adapter, We probably am.(There are times when we just need to design to a particular API and therefore must use an Adapter)
* In the case of the Facade pattern, the motivation is to simplify the interface. With the Adapter, while simpler is better,We are trying to design to an existing interface and cannot simplify things even if a simpler interface were otherwise possible.

Bottom line is a Facade simplifies an interface while an Adapter converts the interface into a pre-existing interface.

=Abstract Factory Pattern and Facade Pattern =

Abstract factory pattern provides a level of indirection that abstracts the creation of families of related or dependent objects without directly specifying their concrete classes. The “factory” object has the responsibility for providing creation services for the entire platform family. Clients never create platform objects directly, they ask the factory to do that for them.

This mechanism makes exchanging product families easy because the specific class of the factory object appears only once in the application - where it is instantiated. The application can wholesale replace the entire family of products simply by instantiating a different concrete instance of the abstract factory. Because the service provided by the factory object is so pervasive, it is routinely implemented as a Singleton. 

== Abstract Factory Example ==
[[File:Abstract.JPG|600px|center]]

The AbstractFactory defines the interface that all of the concrete factories will need to implement in order to product Products. ConcreteFactoryA and ConcreteFactoryB have both implemented this interface here, creating two seperate families of product. Meanwhile, AbstractProductA and AbstractProductB are interfaces for the different types of product. Each factory will create one of each of these AbstractProducts.

The Client deals with AbstractFactory, AbstractProductA and AbstractProductB. It doesn't know anything about the implementations. The actual implementation of AbstractFactory that the Client uses is determined at runtime.

As you can see, one of the main benefits of this pattern is that the client is totally decoupled from the concrete products. Also, new product families can be easily added into the system, by just adding in a new type of ConcreteFactory that implements AbstractFactory, and creating the specific Product implementations.

== Facade Pattern Example ==

[[File:Facade-wo.JPG|300px|thumb|center|Without a Facade, the client has to deal with the intricacies of the sub system.]]

[[File:Facade-w.JPG|300px|thumb|center|With a Facade, the complexities of sub system are unified into a single interface making it readily usable for the client.]]

Considering the example for the Facade pattern, Client requires access to Employee objects, but in order to get that, it first need to contact the Database and retrieve the Company objects. It then retrieves Division objects from them and finally gains access to Employee objects. So, we see that It uses four classes and has to deal with complex details of the sub system. With Facade, the Client is shielded from most of the classes. It uses the Database Facade to retrieve Employee objects directly.

== Differences and similarities between Facade and Abstract Factory patterns ==
<ul>
<li>Facade is a structural design pattern whereas Abstract Factory pattern is a creational design pattern.
<li>Both are similar in a way that both provide an interface. Abstract Factory , provides kind of a Facade for creating products that belongs to its own factories.
<li>With the Abstract Factory Pattern we just provide a common factory builder for many different builders for the same thing. This can be used whenever we need to provide an interface to a set of builders meant to be used with something in common (the product) without bothering on what are we going to build or which factory are we going to use. The Facade pattern instead is used to provide a simple interface to a lot of different operations that the client classes should not see.
</ul>

Thus we see that both patterns achieve quite different goals. The facade pattern is used when you want to hide an implementation or it is about changing interface of some class or set of classes. On the other hand Abstarct factory pattern is used when you want to hide the details on constructing instances. Provide an interface for creating families of related or dependent objects without specifying their concrete classes.

=Mediator Pattern and Facade Pattern=
In Unix, permission to access system resources is managed at three levels of granularity: world, group, and owner. A group is a collection of users intended to model some functional affiliation. Each user on the system can be a member of one or more groups, and each group can have zero or more users assigned to it. Next figure shows three users that are assigned to all three groups. If we were to model this in software, we could decide to have User objects coupled to Group objects, and Group objects coupled to User objects. Then when changes occur, both classes and all their instances would be affected. An alternate approach would be to introduce “an additional level of indirection” - take the mapping of users to groups and groups to users, and make it an abstraction unto itself. This offers several advantages: Users and Groups are decoupled from one another, many mappings can easily be maintained and manipulated simultaneously, and the mapping abstraction can be extended in the future by defining derived classes. 

Partitioning a system into many objects generally enhances reusability, but proliferating interconnections between those objects tend to reduce it again. The mediator object: encapsulates all interconnections, acts as the hub of communication, is responsible for controlling and coordinating the interactions of its clients, and promotes loose coupling by keeping objects from referring to each other explicitly.

[[File:Mediator__1.gif]]

Colleagues (or peers) are not coupled to one another. Each talks to the Mediator, which in turn knows and conducts the orchestration of the others. The “many to many” mapping between colleagues that would otherwise exist, has been “promoted to full object status”. This new abstraction provides a locus of indirection where additional leverage can be hosted.

Mediator is similar to Facade in that it abstracts functionality of existing classes. Mediator abstracts/centralizes arbitrary communication between colleague objects, it routinely “adds value”, and it is known/referenced by the colleague objects (i.e. it defines a multidirectional protocol). In contrast, Facade defines a simpler interface to a subsystem, it doesn’t add new functionality, and it is not known by the subsystem classes (i.e. it defines a unidirectional protocol where it makes requests of the subsystem classes but not vice versa).

=References=

CSC/ECE 517 Fall 2012/ch2b 2w42 aa

2012-11-20T00:40:11Z

Aasawa: /* Facade Pattern Example */

=Introduction =

==Facade Pattern==
Intent 
* Provide a unified interface to a set of interfaces in a subsystem. 
* Wrap a complicated subsystem with a simpler interface. 

Facade discusses encapsulating a complex subsystem within a single interface object. This reduces the learning curve necessary to successfully leverage the subsystem. It also promotes decoupling the subsystem from its potentially many clients. On the other hand, if the Facade is the only access point for the subsystem, it will limit the features and flexibility that “power users” may need. The Facade object should be a fairly simple advocate or facilitator. It should not become an all-knowing oracle or “god” object. 

== Adapter Pattern ==

Intent 
* Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn’t otherwise because of incompatible interfaces. 
* Wrap an existing class with a new interface. 
* Impedance match an old component to a new system. 

Convert the interface of a class into another interface clients expect. Adapter lets classes worktogether that couldn't otherwise because of incompatible interfaces.

==Abstract Factory Pattern==

Intent 
* Provide an interface for creating families of related or dependent objects without specifying their concrete classes. 
* A hierarchy that encapsulates: many possible “platforms”, and the construction of a suite of “products”. 
* The new operator considered harmful. 

If an application is to be portable, it needs to encapsulate platform dependencies. These “platforms” might include: windowing system, operating system, database, etc. Too often, this encapsulatation is not engineered in advance, and lots of #ifdef case statements with options for all currently supported platforms begin to procreate like rabbits throughout the code. 

==Mediator Pattern==
Intent 

* Define an object that encapsulates how a set of objects interact. Mediator promotes loose coupling by keeping objects from referring to each other explicitly, and it lets you vary their interaction independently.
* Design an intermediary to decouple many peers.
* Promote the many-to-many relationships between interacting peers to “full object status”.

=Facade Pattern =

==Non-Software examples==
In most of the Pizza centers, orders will be given through phone calls with the customer interacting with the Customer service representative. In this case, consumers do not have access to the Billing system, Kitchen and delivery department. The customer service representative acts as an interface and interacts with each of the departments involved in the transaction and ensures that Pizzas are delivered to the consumer. Customer Service representative corresponds to the facade. Individual departments involved in the transaction correspond to Sub-systems.

==Software examples==
Web Service Facade Solution Architecture provides an example for Facade design pattern. In this architectural solution, instead of rewriting legacy applications or customizing those with middleware to connect to other applications one by one, this solution helps create a "facade" for the legacy application. Other applications are easily "plugged into" this facade. By modeling a legacy application into its basic functions of create, read, update, and delete and then exposing these functions as Web methods, the Web service facade solution allows other applications to access legacy data by making use of common Web services through standardized protocols. In this way, Facade decouples layers so that they do not depend on each other which can make it easier to develop, to use and to promote code re-use.

== C# Example ==
using System;
using System.Collections.Generic; 
namespace DesignPatterns.Facade
{
public class OrderFacade
{
//Places an Order and Returns an Order ID
public int placeOrder(int CustomerID, List<BasketItem> Products)
{
Order anOrder = new Order();
OrderLine anOrderLine = new OrderLine();
Address DespatchAddress = Address.getCustomerDespatchAddress(CustomerID);
int OrderId = anOrder.requestOrderID();
anOrder.createOrder(OrderId, DespatchAddress);
anOrderLine.addOrderLinesToOrder(OrderId, Products);
return OrderId;
}
} 
//order class
public class Order
{
public int requestOrderID()
{
//Creates and Returns a Unique Order ID
} 
public void createOrder(int OrderId, Address DespatchAddress)
{
}
} 
//OrderLine Class
public class OrderLine
{
public void addOrderLinesToOrder(int OrderId, List<BasketItem> Products)
{
}
} 
//Public Customer
public class Address
{
public static Address getCustomerDespatchAddress(int CustomerID)
{
return new Address();
}
//Address properties
} 
public class BasketItem
{
//BasketItem Properties
}
}

=Adapter Pattern and Facade Pattern =

Adapter functions as a wrapper or modifier of an existing class. It provides a different or translated view of that class. 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. Reuse has always been painful and elusive. One reason has been the tribulation of designing something new, while reusing something old. There is always something not quite right between the old and the new. It may be physical dimensions or misalignment. It may be timing or synchronization. It may be unfortunate assumptions or competing standards. It is like the problem of inserting a new three-prong electrical plug in an old two-prong wall outlet – some kind of adapter or intermediary is necessary. 

Adapter is about creating an intermediary abstraction that translates, or maps, the old component to the new system. Clients call methods on the Adapter object which redirects them into calls to the legacy component. This strategy can be implemented either with inheritance or with aggregation. 

== Adapter Pattern Example ==
<pre>
interface Shape {
void draw(...);
}

Class LegacyLine {
void draw(..) { }
}

Class LegacyRectangle {
void draw(..) { }
}

Class Line implements Shape {
adapter = new LegacyLine();
void draw(...) {adapter.draw(...)}
}

Class Rectangle implements Shape {
adapter = new LegacyRectangle();
void draw(...) {adapter.draw(...)}
}
</pre>

In the example provided for the Facade pattern, the method placeOrder() uses the methods exposed by many other classes such as Order, OrderLine, Address etc to provide a high level view for the callers. The callers need not worry about the complexities in handling the sub-system. The users of the Class OrderFacade just invoke the method placeOrder() with the necessary arguments and rest of the process is taken care by placeOrder(). As can be seen in this case, a new method (placeOrder) was defined which has the logic and the necessary steps to handle all the sub-systems to create an order, create an id for the order, create a dispatch address etc.

In the example provided for the Adapter pattern, no new methods are defined. The existing method draw of LegacyRectangle is wrapped in a adapter class Rectangle. The methods in adapter classes does the necessary manipulations to the arguments and then passes to the original classes.

On similar lines, assume that the implementation and structure of BasketItem in Facade example needs to be changed. To handle such scenario, a new adapter class BasketItemAdapter is defined. It implements all the methods of the BasketItem and in each method makes necessary changes to the arguments and passes it to the new implementation as shown below.
== Example ==
<pre>
public Class BasketItemAdapter {
BasketItem newImplementation = new BasketItem();
void calculateCost(...) {
//make necessary modification
newImplementation.calculateCost(...);
}
}
</pre>

== Differences and similarities ==
* In both the Facade and Adapter pattern we have pre-existing classes.
* In the Facade, however, we do not have an interface we must design to, as we do in the Adapter pattern.
* We are not interested in polymorphic behavior in the Facade, while in the Adapter, We probably am.(There are times when we just need to design to a particular API and therefore must use an Adapter)
* In the case of the Facade pattern, the motivation is to simplify the interface. With the Adapter, while simpler is better,We are trying to design to an existing interface and cannot simplify things even if a simpler interface were otherwise possible.

Bottom line is a Facade simplifies an interface while an Adapter converts the interface into a pre-existing interface.

=Abstract Factory Pattern and Facade Pattern =

Abstract factory pattern provides a level of indirection that abstracts the creation of families of related or dependent objects without directly specifying their concrete classes. The “factory” object has the responsibility for providing creation services for the entire platform family. Clients never create platform objects directly, they ask the factory to do that for them.

This mechanism makes exchanging product families easy because the specific class of the factory object appears only once in the application - where it is instantiated. The application can wholesale replace the entire family of products simply by instantiating a different concrete instance of the abstract factory. Because the service provided by the factory object is so pervasive, it is routinely implemented as a Singleton. 

== Abstract Factory Example ==
[[File:Abstract.JPG|600px|center]]

The AbstractFactory defines the interface that all of the concrete factories will need to implement in order to product Products. ConcreteFactoryA and ConcreteFactoryB have both implemented this interface here, creating two seperate families of product. Meanwhile, AbstractProductA and AbstractProductB are interfaces for the different types of product. Each factory will create one of each of these AbstractProducts.

The Client deals with AbstractFactory, AbstractProductA and AbstractProductB. It doesn't know anything about the implementations. The actual implementation of AbstractFactory that the Client uses is determined at runtime.

As you can see, one of the main benefits of this pattern is that the client is totally decoupled from the concrete products. Also, new product families can be easily added into the system, by just adding in a new type of ConcreteFactory that implements AbstractFactory, and creating the specific Product implementations.

== Facade Pattern Example ==

[[File:Facade-wo.JPG|300px|thumb|center|Without a Facade, the client has to deal with the intricacies of the sub system.]]

[[File:Facade-w.JPG|300px|thumb|center|With a Facade, the complexities of sub system are unified into a single interface making it readily usable for the client.]]

Considering the example for the Facade pattern, Client requires access to Employee objects, but in order to get that, it first need to contact the Database and retrieve the Company objects. It then retrieves Division objects from them and finally gains access to Employee objects. So, we see that It uses four classes and has to deal with complex details of the sub system. With Facade, the Client is shielded from most of the classes. It uses the Database Facade to retrieve Employee objects directly.

Thus we see that both patterns achieve quite different goals. The facade pattern is used when you want to hide an implementation or it is about changing interface of some class or set of classes. On the other hand Abstarct factory pattern is used when you want to hide the details on constructing instances. Provide an interface for creating families of related or dependent objects without specifying their concrete classes.

=Mediator Pattern and Facade Pattern=
In Unix, permission to access system resources is managed at three levels of granularity: world, group, and owner. A group is a collection of users intended to model some functional affiliation. Each user on the system can be a member of one or more groups, and each group can have zero or more users assigned to it. Next figure shows three users that are assigned to all three groups. If we were to model this in software, we could decide to have User objects coupled to Group objects, and Group objects coupled to User objects. Then when changes occur, both classes and all their instances would be affected. An alternate approach would be to introduce “an additional level of indirection” - take the mapping of users to groups and groups to users, and make it an abstraction unto itself. This offers several advantages: Users and Groups are decoupled from one another, many mappings can easily be maintained and manipulated simultaneously, and the mapping abstraction can be extended in the future by defining derived classes. 

Partitioning a system into many objects generally enhances reusability, but proliferating interconnections between those objects tend to reduce it again. The mediator object: encapsulates all interconnections, acts as the hub of communication, is responsible for controlling and coordinating the interactions of its clients, and promotes loose coupling by keeping objects from referring to each other explicitly.

[[File:Mediator__1.gif]]

Colleagues (or peers) are not coupled to one another. Each talks to the Mediator, which in turn knows and conducts the orchestration of the others. The “many to many” mapping between colleagues that would otherwise exist, has been “promoted to full object status”. This new abstraction provides a locus of indirection where additional leverage can be hosted.

Mediator is similar to Facade in that it abstracts functionality of existing classes. Mediator abstracts/centralizes arbitrary communication between colleague objects, it routinely “adds value”, and it is known/referenced by the colleague objects (i.e. it defines a multidirectional protocol). In contrast, Facade defines a simpler interface to a subsystem, it doesn’t add new functionality, and it is not known by the subsystem classes (i.e. it defines a unidirectional protocol where it makes requests of the subsystem classes but not vice versa).

=References=

CSC/ECE 517 Fall 2012/ch2b 2w42 aa

2012-11-20T00:36:36Z

Aasawa: /* Facade Pattern Example */

=Introduction =

==Facade Pattern==
Intent 
* Provide a unified interface to a set of interfaces in a subsystem. 
* Wrap a complicated subsystem with a simpler interface. 

Facade discusses encapsulating a complex subsystem within a single interface object. This reduces the learning curve necessary to successfully leverage the subsystem. It also promotes decoupling the subsystem from its potentially many clients. On the other hand, if the Facade is the only access point for the subsystem, it will limit the features and flexibility that “power users” may need. The Facade object should be a fairly simple advocate or facilitator. It should not become an all-knowing oracle or “god” object. 

== Adapter Pattern ==

Intent 
* Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn’t otherwise because of incompatible interfaces. 
* Wrap an existing class with a new interface. 
* Impedance match an old component to a new system. 

Convert the interface of a class into another interface clients expect. Adapter lets classes worktogether that couldn't otherwise because of incompatible interfaces.

==Abstract Factory Pattern==

Intent 
* Provide an interface for creating families of related or dependent objects without specifying their concrete classes. 
* A hierarchy that encapsulates: many possible “platforms”, and the construction of a suite of “products”. 
* The new operator considered harmful. 

If an application is to be portable, it needs to encapsulate platform dependencies. These “platforms” might include: windowing system, operating system, database, etc. Too often, this encapsulatation is not engineered in advance, and lots of #ifdef case statements with options for all currently supported platforms begin to procreate like rabbits throughout the code. 

==Mediator Pattern==
Intent 

* Define an object that encapsulates how a set of objects interact. Mediator promotes loose coupling by keeping objects from referring to each other explicitly, and it lets you vary their interaction independently.
* Design an intermediary to decouple many peers.
* Promote the many-to-many relationships between interacting peers to “full object status”.

=Facade Pattern =

==Non-Software examples==
In most of the Pizza centers, orders will be given through phone calls with the customer interacting with the Customer service representative. In this case, consumers do not have access to the Billing system, Kitchen and delivery department. The customer service representative acts as an interface and interacts with each of the departments involved in the transaction and ensures that Pizzas are delivered to the consumer. Customer Service representative corresponds to the facade. Individual departments involved in the transaction correspond to Sub-systems.

==Software examples==
Web Service Facade Solution Architecture provides an example for Facade design pattern. In this architectural solution, instead of rewriting legacy applications or customizing those with middleware to connect to other applications one by one, this solution helps create a "facade" for the legacy application. Other applications are easily "plugged into" this facade. By modeling a legacy application into its basic functions of create, read, update, and delete and then exposing these functions as Web methods, the Web service facade solution allows other applications to access legacy data by making use of common Web services through standardized protocols. In this way, Facade decouples layers so that they do not depend on each other which can make it easier to develop, to use and to promote code re-use.

== C# Example ==
using System;
using System.Collections.Generic; 
namespace DesignPatterns.Facade
{
public class OrderFacade
{
//Places an Order and Returns an Order ID
public int placeOrder(int CustomerID, List<BasketItem> Products)
{
Order anOrder = new Order();
OrderLine anOrderLine = new OrderLine();
Address DespatchAddress = Address.getCustomerDespatchAddress(CustomerID);
int OrderId = anOrder.requestOrderID();
anOrder.createOrder(OrderId, DespatchAddress);
anOrderLine.addOrderLinesToOrder(OrderId, Products);
return OrderId;
}
} 
//order class
public class Order
{
public int requestOrderID()
{
//Creates and Returns a Unique Order ID
} 
public void createOrder(int OrderId, Address DespatchAddress)
{
}
} 
//OrderLine Class
public class OrderLine
{
public void addOrderLinesToOrder(int OrderId, List<BasketItem> Products)
{
}
} 
//Public Customer
public class Address
{
public static Address getCustomerDespatchAddress(int CustomerID)
{
return new Address();
}
//Address properties
} 
public class BasketItem
{
//BasketItem Properties
}
}

=Adapter Pattern and Facade Pattern =

Adapter functions as a wrapper or modifier of an existing class. It provides a different or translated view of that class. 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. Reuse has always been painful and elusive. One reason has been the tribulation of designing something new, while reusing something old. There is always something not quite right between the old and the new. It may be physical dimensions or misalignment. It may be timing or synchronization. It may be unfortunate assumptions or competing standards. It is like the problem of inserting a new three-prong electrical plug in an old two-prong wall outlet – some kind of adapter or intermediary is necessary. 

Adapter is about creating an intermediary abstraction that translates, or maps, the old component to the new system. Clients call methods on the Adapter object which redirects them into calls to the legacy component. This strategy can be implemented either with inheritance or with aggregation. 

== Adapter Pattern Example ==
<pre>
interface Shape {
void draw(...);
}

Class LegacyLine {
void draw(..) { }
}

Class LegacyRectangle {
void draw(..) { }
}

Class Line implements Shape {
adapter = new LegacyLine();
void draw(...) {adapter.draw(...)}
}

Class Rectangle implements Shape {
adapter = new LegacyRectangle();
void draw(...) {adapter.draw(...)}
}
</pre>

In the example provided for the Facade pattern, the method placeOrder() uses the methods exposed by many other classes such as Order, OrderLine, Address etc to provide a high level view for the callers. The callers need not worry about the complexities in handling the sub-system. The users of the Class OrderFacade just invoke the method placeOrder() with the necessary arguments and rest of the process is taken care by placeOrder(). As can be seen in this case, a new method (placeOrder) was defined which has the logic and the necessary steps to handle all the sub-systems to create an order, create an id for the order, create a dispatch address etc.

In the example provided for the Adapter pattern, no new methods are defined. The existing method draw of LegacyRectangle is wrapped in a adapter class Rectangle. The methods in adapter classes does the necessary manipulations to the arguments and then passes to the original classes.

On similar lines, assume that the implementation and structure of BasketItem in Facade example needs to be changed. To handle such scenario, a new adapter class BasketItemAdapter is defined. It implements all the methods of the BasketItem and in each method makes necessary changes to the arguments and passes it to the new implementation as shown below.
== Example ==
<pre>
public Class BasketItemAdapter {
BasketItem newImplementation = new BasketItem();
void calculateCost(...) {
//make necessary modification
newImplementation.calculateCost(...);
}
}
</pre>

== Differences and similarities ==
* In both the Facade and Adapter pattern we have pre-existing classes.
* In the Facade, however, we do not have an interface we must design to, as we do in the Adapter pattern.
* We are not interested in polymorphic behavior in the Facade, while in the Adapter, We probably am.(There are times when we just need to design to a particular API and therefore must use an Adapter)
* In the case of the Facade pattern, the motivation is to simplify the interface. With the Adapter, while simpler is better,We are trying to design to an existing interface and cannot simplify things even if a simpler interface were otherwise possible.

Bottom line is a Facade simplifies an interface while an Adapter converts the interface into a pre-existing interface.

=Abstract Factory Pattern and Facade Pattern =

Abstract factory pattern provides a level of indirection that abstracts the creation of families of related or dependent objects without directly specifying their concrete classes. The “factory” object has the responsibility for providing creation services for the entire platform family. Clients never create platform objects directly, they ask the factory to do that for them.

This mechanism makes exchanging product families easy because the specific class of the factory object appears only once in the application - where it is instantiated. The application can wholesale replace the entire family of products simply by instantiating a different concrete instance of the abstract factory. Because the service provided by the factory object is so pervasive, it is routinely implemented as a Singleton. 

== Abstract Factory Example ==
[[File:Abstract.JPG|600px|center]]

The AbstractFactory defines the interface that all of the concrete factories will need to implement in order to product Products. ConcreteFactoryA and ConcreteFactoryB have both implemented this interface here, creating two seperate families of product. Meanwhile, AbstractProductA and AbstractProductB are interfaces for the different types of product. Each factory will create one of each of these AbstractProducts.

The Client deals with AbstractFactory, AbstractProductA and AbstractProductB. It doesn't know anything about the implementations. The actual implementation of AbstractFactory that the Client uses is determined at runtime.

As you can see, one of the main benefits of this pattern is that the client is totally decoupled from the concrete products. Also, new product families can be easily added into the system, by just adding in a new type of ConcreteFactory that implements AbstractFactory, and creating the specific Product implementations.

== Facade Pattern Example ==

[[File:Facade-wo.JPG|300px|thumb|center|Without a Facade, the client has to deal with the intricacies of the sub system.]]

[[File:Facade-w.JPG|300px|thumb|center|With a Facade, the complexities of sub system are unified into a single interface making it readily usable for the client.]]

Considering the example for the Facade pattern, Client requires access to Employee objects, but in order to get that, it first need to contact the Database and retrieve the Company objects. It then retrieves Division objects from them and finally gains access to Employee objects. So, we see that It uses four classes and has to deal with complex details of the sub system. With Facade, the Client is shielded from most of the classes. It uses the Database Facade to retrieve Employee objects directly.

=Mediator Pattern and Facade Pattern=
In Unix, permission to access system resources is managed at three levels of granularity: world, group, and owner. A group is a collection of users intended to model some functional affiliation. Each user on the system can be a member of one or more groups, and each group can have zero or more users assigned to it. Next figure shows three users that are assigned to all three groups. If we were to model this in software, we could decide to have User objects coupled to Group objects, and Group objects coupled to User objects. Then when changes occur, both classes and all their instances would be affected. An alternate approach would be to introduce “an additional level of indirection” - take the mapping of users to groups and groups to users, and make it an abstraction unto itself. This offers several advantages: Users and Groups are decoupled from one another, many mappings can easily be maintained and manipulated simultaneously, and the mapping abstraction can be extended in the future by defining derived classes. 

Partitioning a system into many objects generally enhances reusability, but proliferating interconnections between those objects tend to reduce it again. The mediator object: encapsulates all interconnections, acts as the hub of communication, is responsible for controlling and coordinating the interactions of its clients, and promotes loose coupling by keeping objects from referring to each other explicitly.

[[File:Mediator__1.gif]]

Colleagues (or peers) are not coupled to one another. Each talks to the Mediator, which in turn knows and conducts the orchestration of the others. The “many to many” mapping between colleagues that would otherwise exist, has been “promoted to full object status”. This new abstraction provides a locus of indirection where additional leverage can be hosted.

Mediator is similar to Facade in that it abstracts functionality of existing classes. Mediator abstracts/centralizes arbitrary communication between colleague objects, it routinely “adds value”, and it is known/referenced by the colleague objects (i.e. it defines a multidirectional protocol). In contrast, Facade defines a simpler interface to a subsystem, it doesn’t add new functionality, and it is not known by the subsystem classes (i.e. it defines a unidirectional protocol where it makes requests of the subsystem classes but not vice versa).

=References=

CSC/ECE 517 Fall 2012/ch2b 2w42 aa

2012-11-20T00:32:12Z

Aasawa: /* Abstract Factory Example */

=Introduction =

==Facade Pattern==
Intent 
* Provide a unified interface to a set of interfaces in a subsystem. 
* Wrap a complicated subsystem with a simpler interface. 

Facade discusses encapsulating a complex subsystem within a single interface object. This reduces the learning curve necessary to successfully leverage the subsystem. It also promotes decoupling the subsystem from its potentially many clients. On the other hand, if the Facade is the only access point for the subsystem, it will limit the features and flexibility that “power users” may need. The Facade object should be a fairly simple advocate or facilitator. It should not become an all-knowing oracle or “god” object. 

== Adapter Pattern ==

Intent 
* Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn’t otherwise because of incompatible interfaces. 
* Wrap an existing class with a new interface. 
* Impedance match an old component to a new system. 

Convert the interface of a class into another interface clients expect. Adapter lets classes worktogether that couldn't otherwise because of incompatible interfaces.

==Abstract Factory Pattern==

Intent 
* Provide an interface for creating families of related or dependent objects without specifying their concrete classes. 
* A hierarchy that encapsulates: many possible “platforms”, and the construction of a suite of “products”. 
* The new operator considered harmful. 

If an application is to be portable, it needs to encapsulate platform dependencies. These “platforms” might include: windowing system, operating system, database, etc. Too often, this encapsulatation is not engineered in advance, and lots of #ifdef case statements with options for all currently supported platforms begin to procreate like rabbits throughout the code. 

==Mediator Pattern==
Intent 

* Define an object that encapsulates how a set of objects interact. Mediator promotes loose coupling by keeping objects from referring to each other explicitly, and it lets you vary their interaction independently.
* Design an intermediary to decouple many peers.
* Promote the many-to-many relationships between interacting peers to “full object status”.

=Facade Pattern =

==Non-Software examples==
In most of the Pizza centers, orders will be given through phone calls with the customer interacting with the Customer service representative. In this case, consumers do not have access to the Billing system, Kitchen and delivery department. The customer service representative acts as an interface and interacts with each of the departments involved in the transaction and ensures that Pizzas are delivered to the consumer. Customer Service representative corresponds to the facade. Individual departments involved in the transaction correspond to Sub-systems.

==Software examples==
Web Service Facade Solution Architecture provides an example for Facade design pattern. In this architectural solution, instead of rewriting legacy applications or customizing those with middleware to connect to other applications one by one, this solution helps create a "facade" for the legacy application. Other applications are easily "plugged into" this facade. By modeling a legacy application into its basic functions of create, read, update, and delete and then exposing these functions as Web methods, the Web service facade solution allows other applications to access legacy data by making use of common Web services through standardized protocols. In this way, Facade decouples layers so that they do not depend on each other which can make it easier to develop, to use and to promote code re-use.

== C# Example ==
using System;
using System.Collections.Generic; 
namespace DesignPatterns.Facade
{
public class OrderFacade
{
//Places an Order and Returns an Order ID
public int placeOrder(int CustomerID, List<BasketItem> Products)
{
Order anOrder = new Order();
OrderLine anOrderLine = new OrderLine();
Address DespatchAddress = Address.getCustomerDespatchAddress(CustomerID);
int OrderId = anOrder.requestOrderID();
anOrder.createOrder(OrderId, DespatchAddress);
anOrderLine.addOrderLinesToOrder(OrderId, Products);
return OrderId;
}
} 
//order class
public class Order
{
public int requestOrderID()
{
//Creates and Returns a Unique Order ID
} 
public void createOrder(int OrderId, Address DespatchAddress)
{
}
} 
//OrderLine Class
public class OrderLine
{
public void addOrderLinesToOrder(int OrderId, List<BasketItem> Products)
{
}
} 
//Public Customer
public class Address
{
public static Address getCustomerDespatchAddress(int CustomerID)
{
return new Address();
}
//Address properties
} 
public class BasketItem
{
//BasketItem Properties
}
}

=Adapter Pattern and Facade Pattern =

Adapter functions as a wrapper or modifier of an existing class. It provides a different or translated view of that class. 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. Reuse has always been painful and elusive. One reason has been the tribulation of designing something new, while reusing something old. There is always something not quite right between the old and the new. It may be physical dimensions or misalignment. It may be timing or synchronization. It may be unfortunate assumptions or competing standards. It is like the problem of inserting a new three-prong electrical plug in an old two-prong wall outlet – some kind of adapter or intermediary is necessary. 

Adapter is about creating an intermediary abstraction that translates, or maps, the old component to the new system. Clients call methods on the Adapter object which redirects them into calls to the legacy component. This strategy can be implemented either with inheritance or with aggregation. 

== Adapter Pattern Example ==
<pre>
interface Shape {
void draw(...);
}

Class LegacyLine {
void draw(..) { }
}

Class LegacyRectangle {
void draw(..) { }
}

Class Line implements Shape {
adapter = new LegacyLine();
void draw(...) {adapter.draw(...)}
}

Class Rectangle implements Shape {
adapter = new LegacyRectangle();
void draw(...) {adapter.draw(...)}
}
</pre>

In the example provided for the Facade pattern, the method placeOrder() uses the methods exposed by many other classes such as Order, OrderLine, Address etc to provide a high level view for the callers. The callers need not worry about the complexities in handling the sub-system. The users of the Class OrderFacade just invoke the method placeOrder() with the necessary arguments and rest of the process is taken care by placeOrder(). As can be seen in this case, a new method (placeOrder) was defined which has the logic and the necessary steps to handle all the sub-systems to create an order, create an id for the order, create a dispatch address etc.

In the example provided for the Adapter pattern, no new methods are defined. The existing method draw of LegacyRectangle is wrapped in a adapter class Rectangle. The methods in adapter classes does the necessary manipulations to the arguments and then passes to the original classes.

On similar lines, assume that the implementation and structure of BasketItem in Facade example needs to be changed. To handle such scenario, a new adapter class BasketItemAdapter is defined. It implements all the methods of the BasketItem and in each method makes necessary changes to the arguments and passes it to the new implementation as shown below.
== Example ==
<pre>
public Class BasketItemAdapter {
BasketItem newImplementation = new BasketItem();
void calculateCost(...) {
//make necessary modification
newImplementation.calculateCost(...);
}
}
</pre>

== Differences and similarities ==
* In both the Facade and Adapter pattern we have pre-existing classes.
* In the Facade, however, we do not have an interface we must design to, as we do in the Adapter pattern.
* We are not interested in polymorphic behavior in the Facade, while in the Adapter, We probably am.(There are times when we just need to design to a particular API and therefore must use an Adapter)
* In the case of the Facade pattern, the motivation is to simplify the interface. With the Adapter, while simpler is better,We are trying to design to an existing interface and cannot simplify things even if a simpler interface were otherwise possible.

Bottom line is a Facade simplifies an interface while an Adapter converts the interface into a pre-existing interface.

=Abstract Factory Pattern and Facade Pattern =

Abstract factory pattern provides a level of indirection that abstracts the creation of families of related or dependent objects without directly specifying their concrete classes. The “factory” object has the responsibility for providing creation services for the entire platform family. Clients never create platform objects directly, they ask the factory to do that for them.

This mechanism makes exchanging product families easy because the specific class of the factory object appears only once in the application - where it is instantiated. The application can wholesale replace the entire family of products simply by instantiating a different concrete instance of the abstract factory. Because the service provided by the factory object is so pervasive, it is routinely implemented as a Singleton. 

== Abstract Factory Example ==
[[File:Abstract.JPG|600px|center]]

The AbstractFactory defines the interface that all of the concrete factories will need to implement in order to product Products. ConcreteFactoryA and ConcreteFactoryB have both implemented this interface here, creating two seperate families of product. Meanwhile, AbstractProductA and AbstractProductB are interfaces for the different types of product. Each factory will create one of each of these AbstractProducts.

The Client deals with AbstractFactory, AbstractProductA and AbstractProductB. It doesn't know anything about the implementations. The actual implementation of AbstractFactory that the Client uses is determined at runtime.

As you can see, one of the main benefits of this pattern is that the client is totally decoupled from the concrete products. Also, new product families can be easily added into the system, by just adding in a new type of ConcreteFactory that implements AbstractFactory, and creating the specific Product implementations.

== Facade Pattern Example ==

[[File:Facade-wo.JPG|300px|thumb|center|Without a Facade, the client has to deal with the intricacies of the sub system.]]

[[File:Facade-w.JPG|300px|thumb|center|With a Facade, the complexities of sub system are unified into a single interface making it readily usable for the client.]]

Client contacts the Database to retrieve Company objects. It then retrieves Division objects from them and finally gains access to Employee objects.It uses four classes. With Facade, the Client is shielded from most of the classes. It uses the Database Facade to retrieve Employee objects directly.

=Mediator Pattern and Facade Pattern=
In Unix, permission to access system resources is managed at three levels of granularity: world, group, and owner. A group is a collection of users intended to model some functional affiliation. Each user on the system can be a member of one or more groups, and each group can have zero or more users assigned to it. Next figure shows three users that are assigned to all three groups. If we were to model this in software, we could decide to have User objects coupled to Group objects, and Group objects coupled to User objects. Then when changes occur, both classes and all their instances would be affected. An alternate approach would be to introduce “an additional level of indirection” - take the mapping of users to groups and groups to users, and make it an abstraction unto itself. This offers several advantages: Users and Groups are decoupled from one another, many mappings can easily be maintained and manipulated simultaneously, and the mapping abstraction can be extended in the future by defining derived classes. 

Partitioning a system into many objects generally enhances reusability, but proliferating interconnections between those objects tend to reduce it again. The mediator object: encapsulates all interconnections, acts as the hub of communication, is responsible for controlling and coordinating the interactions of its clients, and promotes loose coupling by keeping objects from referring to each other explicitly.

[[File:Mediator__1.gif]]

Colleagues (or peers) are not coupled to one another. Each talks to the Mediator, which in turn knows and conducts the orchestration of the others. The “many to many” mapping between colleagues that would otherwise exist, has been “promoted to full object status”. This new abstraction provides a locus of indirection where additional leverage can be hosted.

Mediator is similar to Facade in that it abstracts functionality of existing classes. Mediator abstracts/centralizes arbitrary communication between colleague objects, it routinely “adds value”, and it is known/referenced by the colleague objects (i.e. it defines a multidirectional protocol). In contrast, Facade defines a simpler interface to a subsystem, it doesn’t add new functionality, and it is not known by the subsystem classes (i.e. it defines a unidirectional protocol where it makes requests of the subsystem classes but not vice versa).

=References=

CSC/ECE 517 Fall 2012/ch2b 2w42 aa

2012-11-20T00:30:12Z

Aasawa: /* Facade Pattern Example */

=Introduction =

==Facade Pattern==
Intent 
* Provide a unified interface to a set of interfaces in a subsystem. 
* Wrap a complicated subsystem with a simpler interface. 

Facade discusses encapsulating a complex subsystem within a single interface object. This reduces the learning curve necessary to successfully leverage the subsystem. It also promotes decoupling the subsystem from its potentially many clients. On the other hand, if the Facade is the only access point for the subsystem, it will limit the features and flexibility that “power users” may need. The Facade object should be a fairly simple advocate or facilitator. It should not become an all-knowing oracle or “god” object. 

== Adapter Pattern ==

Intent 
* Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn’t otherwise because of incompatible interfaces. 
* Wrap an existing class with a new interface. 
* Impedance match an old component to a new system. 

Convert the interface of a class into another interface clients expect. Adapter lets classes worktogether that couldn't otherwise because of incompatible interfaces.

==Abstract Factory Pattern==

Intent 
* Provide an interface for creating families of related or dependent objects without specifying their concrete classes. 
* A hierarchy that encapsulates: many possible “platforms”, and the construction of a suite of “products”. 
* The new operator considered harmful. 

If an application is to be portable, it needs to encapsulate platform dependencies. These “platforms” might include: windowing system, operating system, database, etc. Too often, this encapsulatation is not engineered in advance, and lots of #ifdef case statements with options for all currently supported platforms begin to procreate like rabbits throughout the code. 

==Mediator Pattern==
Intent 

* Define an object that encapsulates how a set of objects interact. Mediator promotes loose coupling by keeping objects from referring to each other explicitly, and it lets you vary their interaction independently.
* Design an intermediary to decouple many peers.
* Promote the many-to-many relationships between interacting peers to “full object status”.

=Facade Pattern =

==Non-Software examples==
In most of the Pizza centers, orders will be given through phone calls with the customer interacting with the Customer service representative. In this case, consumers do not have access to the Billing system, Kitchen and delivery department. The customer service representative acts as an interface and interacts with each of the departments involved in the transaction and ensures that Pizzas are delivered to the consumer. Customer Service representative corresponds to the facade. Individual departments involved in the transaction correspond to Sub-systems.

==Software examples==
Web Service Facade Solution Architecture provides an example for Facade design pattern. In this architectural solution, instead of rewriting legacy applications or customizing those with middleware to connect to other applications one by one, this solution helps create a "facade" for the legacy application. Other applications are easily "plugged into" this facade. By modeling a legacy application into its basic functions of create, read, update, and delete and then exposing these functions as Web methods, the Web service facade solution allows other applications to access legacy data by making use of common Web services through standardized protocols. In this way, Facade decouples layers so that they do not depend on each other which can make it easier to develop, to use and to promote code re-use.

== C# Example ==
using System;
using System.Collections.Generic; 
namespace DesignPatterns.Facade
{
public class OrderFacade
{
//Places an Order and Returns an Order ID
public int placeOrder(int CustomerID, List<BasketItem> Products)
{
Order anOrder = new Order();
OrderLine anOrderLine = new OrderLine();
Address DespatchAddress = Address.getCustomerDespatchAddress(CustomerID);
int OrderId = anOrder.requestOrderID();
anOrder.createOrder(OrderId, DespatchAddress);
anOrderLine.addOrderLinesToOrder(OrderId, Products);
return OrderId;
}
} 
//order class
public class Order
{
public int requestOrderID()
{
//Creates and Returns a Unique Order ID
} 
public void createOrder(int OrderId, Address DespatchAddress)
{
}
} 
//OrderLine Class
public class OrderLine
{
public void addOrderLinesToOrder(int OrderId, List<BasketItem> Products)
{
}
} 
//Public Customer
public class Address
{
public static Address getCustomerDespatchAddress(int CustomerID)
{
return new Address();
}
//Address properties
} 
public class BasketItem
{
//BasketItem Properties
}
}

=Adapter Pattern and Facade Pattern =

Adapter functions as a wrapper or modifier of an existing class. It provides a different or translated view of that class. 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. Reuse has always been painful and elusive. One reason has been the tribulation of designing something new, while reusing something old. There is always something not quite right between the old and the new. It may be physical dimensions or misalignment. It may be timing or synchronization. It may be unfortunate assumptions or competing standards. It is like the problem of inserting a new three-prong electrical plug in an old two-prong wall outlet – some kind of adapter or intermediary is necessary. 

Adapter is about creating an intermediary abstraction that translates, or maps, the old component to the new system. Clients call methods on the Adapter object which redirects them into calls to the legacy component. This strategy can be implemented either with inheritance or with aggregation. 

== Adapter Pattern Example ==
<pre>
interface Shape {
void draw(...);
}

Class LegacyLine {
void draw(..) { }
}

Class LegacyRectangle {
void draw(..) { }
}

Class Line implements Shape {
adapter = new LegacyLine();
void draw(...) {adapter.draw(...)}
}

Class Rectangle implements Shape {
adapter = new LegacyRectangle();
void draw(...) {adapter.draw(...)}
}
</pre>

In the example provided for the Facade pattern, the method placeOrder() uses the methods exposed by many other classes such as Order, OrderLine, Address etc to provide a high level view for the callers. The callers need not worry about the complexities in handling the sub-system. The users of the Class OrderFacade just invoke the method placeOrder() with the necessary arguments and rest of the process is taken care by placeOrder(). As can be seen in this case, a new method (placeOrder) was defined which has the logic and the necessary steps to handle all the sub-systems to create an order, create an id for the order, create a dispatch address etc.

In the example provided for the Adapter pattern, no new methods are defined. The existing method draw of LegacyRectangle is wrapped in a adapter class Rectangle. The methods in adapter classes does the necessary manipulations to the arguments and then passes to the original classes.

On similar lines, assume that the implementation and structure of BasketItem in Facade example needs to be changed. To handle such scenario, a new adapter class BasketItemAdapter is defined. It implements all the methods of the BasketItem and in each method makes necessary changes to the arguments and passes it to the new implementation as shown below.
== Example ==
<pre>
public Class BasketItemAdapter {
BasketItem newImplementation = new BasketItem();
void calculateCost(...) {
//make necessary modification
newImplementation.calculateCost(...);
}
}
</pre>

=Abstract Factory Pattern and Facade Pattern =

Abstract factory pattern provides a level of indirection that abstracts the creation of families of related or dependent objects without directly specifying their concrete classes. The “factory” object has the responsibility for providing creation services for the entire platform family. Clients never create platform objects directly, they ask the factory to do that for them.

This mechanism makes exchanging product families easy because the specific class of the factory object appears only once in the application - where it is instantiated. The application can wholesale replace the entire family of products simply by instantiating a different concrete instance of the abstract factory. Because the service provided by the factory object is so pervasive, it is routinely implemented as a Singleton. 

== Abstract Factory Example ==
[[File:Abstract.JPG|600px|center]]

The AbstractFactory defines the interface that all of the concrete factories will need to implement in order to product Products. ConcreteFactoryA and ConcreteFactoryB have both implemented this interface here, creating two seperate families of product. Meanwhile, AbstractProductA and AbstractProductB are interfaces for the different types of product. Each factory will create one of each of these AbstractProducts.

The Client deals with AbstractFactory, AbstractProductA and AbstractProductB. It doesn't know anything about the implementations. The actual implementation of AbstractFactory that the Client uses is determined at runtime.

As you can see, one of the main benefits of this pattern is that the client is totally decoupled from the concrete products. Also, new product families can be easily added into the system, by just adding in a new type of ConcreteFactory that implements AbstractFactory, and creating the specific Product implementations.

== Facade Pattern Example ==

[[File:Facade-wo.JPG|300px|thumb|center|Without a Facade, the client has to deal with the intricacies of the sub system.]]

[[File:Facade-w.JPG|300px|thumb|center|With a Facade, the complexities of sub system are unified into a single interface making it readily usable for the client.]]

Client contacts the Database to retrieve Company objects. It then retrieves Division objects from them and finally gains access to Employee objects.It uses four classes. With Facade, the Client is shielded from most of the classes. It uses the Database Facade to retrieve Employee objects directly.

=Mediator Pattern and Facade Pattern =
In Unix, permission to access system resources is managed at three levels of granularity: world, group, and owner. A group is a collection of users intended to model some functional affiliation. Each user on the system can be a member of one or more groups, and each group can have zero or more users assigned to it. Next figure shows three users that are assigned to all three groups. If we were to model this in software, we could decide to have User objects coupled to Group objects, and Group objects coupled to User objects. Then when changes occur, both classes and all their instances would be affected. An alternate approach would be to introduce “an additional level of indirection” - take the mapping of users to groups and groups to users, and make it an abstraction unto itself. This offers several advantages: Users and Groups are decoupled from one another, many mappings can easily be maintained and manipulated simultaneously, and the mapping abstraction can be extended in the future by defining derived classes. 

Partitioning a system into many objects generally enhances reusability, but proliferating interconnections between those objects tend to reduce it again. The mediator object: encapsulates all interconnections, acts as the hub of communication, is responsible for controlling and coordinating the interactions of its clients, and promotes loose coupling by keeping objects from referring to each other explicitly.

[[File:Mediator__1.gif]]

Colleagues (or peers) are not coupled to one another. Each talks to the Mediator, which in turn knows and conducts the orchestration of the others. The “many to many” mapping between colleagues that would otherwise exist, has been “promoted to full object status”. This new abstraction provides a locus of indirection where additional leverage can be hosted.

Mediator is similar to Facade in that it abstracts functionality of existing classes. Mediator abstracts/centralizes arbitrary communication between colleague objects, it routinely “adds value”, and it is known/referenced by the colleague objects (i.e. it defines a multidirectional protocol). In contrast, Facade defines a simpler interface to a subsystem, it doesn’t add new functionality, and it is not known by the subsystem classes (i.e. it defines a unidirectional protocol where it makes requests of the subsystem classes but not vice versa).

CSC/ECE 517 Fall 2012/ch2b 2w42 aa

2012-11-20T00:29:55Z

Aasawa: /* Facade Pattern Example */

=Introduction =

==Facade Pattern==
Intent 
* Provide a unified interface to a set of interfaces in a subsystem. 
* Wrap a complicated subsystem with a simpler interface. 

Facade discusses encapsulating a complex subsystem within a single interface object. This reduces the learning curve necessary to successfully leverage the subsystem. It also promotes decoupling the subsystem from its potentially many clients. On the other hand, if the Facade is the only access point for the subsystem, it will limit the features and flexibility that “power users” may need. The Facade object should be a fairly simple advocate or facilitator. It should not become an all-knowing oracle or “god” object. 

== Adapter Pattern ==

Intent 
* Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn’t otherwise because of incompatible interfaces. 
* Wrap an existing class with a new interface. 
* Impedance match an old component to a new system. 

Convert the interface of a class into another interface clients expect. Adapter lets classes worktogether that couldn't otherwise because of incompatible interfaces.

==Abstract Factory Pattern==

Intent 
* Provide an interface for creating families of related or dependent objects without specifying their concrete classes. 
* A hierarchy that encapsulates: many possible “platforms”, and the construction of a suite of “products”. 
* The new operator considered harmful. 

If an application is to be portable, it needs to encapsulate platform dependencies. These “platforms” might include: windowing system, operating system, database, etc. Too often, this encapsulatation is not engineered in advance, and lots of #ifdef case statements with options for all currently supported platforms begin to procreate like rabbits throughout the code. 

==Mediator Pattern==
Intent 

* Define an object that encapsulates how a set of objects interact. Mediator promotes loose coupling by keeping objects from referring to each other explicitly, and it lets you vary their interaction independently.
* Design an intermediary to decouple many peers.
* Promote the many-to-many relationships between interacting peers to “full object status”.

=Facade Pattern =

==Non-Software examples==
In most of the Pizza centers, orders will be given through phone calls with the customer interacting with the Customer service representative. In this case, consumers do not have access to the Billing system, Kitchen and delivery department. The customer service representative acts as an interface and interacts with each of the departments involved in the transaction and ensures that Pizzas are delivered to the consumer. Customer Service representative corresponds to the facade. Individual departments involved in the transaction correspond to Sub-systems.

==Software examples==
Web Service Facade Solution Architecture provides an example for Facade design pattern. In this architectural solution, instead of rewriting legacy applications or customizing those with middleware to connect to other applications one by one, this solution helps create a "facade" for the legacy application. Other applications are easily "plugged into" this facade. By modeling a legacy application into its basic functions of create, read, update, and delete and then exposing these functions as Web methods, the Web service facade solution allows other applications to access legacy data by making use of common Web services through standardized protocols. In this way, Facade decouples layers so that they do not depend on each other which can make it easier to develop, to use and to promote code re-use.

== C# Example ==
using System;
using System.Collections.Generic; 
namespace DesignPatterns.Facade
{
public class OrderFacade
{
//Places an Order and Returns an Order ID
public int placeOrder(int CustomerID, List<BasketItem> Products)
{
Order anOrder = new Order();
OrderLine anOrderLine = new OrderLine();
Address DespatchAddress = Address.getCustomerDespatchAddress(CustomerID);
int OrderId = anOrder.requestOrderID();
anOrder.createOrder(OrderId, DespatchAddress);
anOrderLine.addOrderLinesToOrder(OrderId, Products);
return OrderId;
}
} 
//order class
public class Order
{
public int requestOrderID()
{
//Creates and Returns a Unique Order ID
} 
public void createOrder(int OrderId, Address DespatchAddress)
{
}
} 
//OrderLine Class
public class OrderLine
{
public void addOrderLinesToOrder(int OrderId, List<BasketItem> Products)
{
}
} 
//Public Customer
public class Address
{
public static Address getCustomerDespatchAddress(int CustomerID)
{
return new Address();
}
//Address properties
} 
public class BasketItem
{
//BasketItem Properties
}
}

=Adapter Pattern and Facade Pattern =

Adapter functions as a wrapper or modifier of an existing class. It provides a different or translated view of that class. 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. Reuse has always been painful and elusive. One reason has been the tribulation of designing something new, while reusing something old. There is always something not quite right between the old and the new. It may be physical dimensions or misalignment. It may be timing or synchronization. It may be unfortunate assumptions or competing standards. It is like the problem of inserting a new three-prong electrical plug in an old two-prong wall outlet – some kind of adapter or intermediary is necessary. 

Adapter is about creating an intermediary abstraction that translates, or maps, the old component to the new system. Clients call methods on the Adapter object which redirects them into calls to the legacy component. This strategy can be implemented either with inheritance or with aggregation. 

== Adapter Pattern Example ==
<pre>
interface Shape {
void draw(...);
}

Class LegacyLine {
void draw(..) { }
}

Class LegacyRectangle {
void draw(..) { }
}

Class Line implements Shape {
adapter = new LegacyLine();
void draw(...) {adapter.draw(...)}
}

Class Rectangle implements Shape {
adapter = new LegacyRectangle();
void draw(...) {adapter.draw(...)}
}
</pre>

In the example provided for the Facade pattern, the method placeOrder() uses the methods exposed by many other classes such as Order, OrderLine, Address etc to provide a high level view for the callers. The callers need not worry about the complexities in handling the sub-system. The users of the Class OrderFacade just invoke the method placeOrder() with the necessary arguments and rest of the process is taken care by placeOrder(). As can be seen in this case, a new method (placeOrder) was defined which has the logic and the necessary steps to handle all the sub-systems to create an order, create an id for the order, create a dispatch address etc.

In the example provided for the Adapter pattern, no new methods are defined. The existing method draw of LegacyRectangle is wrapped in a adapter class Rectangle. The methods in adapter classes does the necessary manipulations to the arguments and then passes to the original classes.

On similar lines, assume that the implementation and structure of BasketItem in Facade example needs to be changed. To handle such scenario, a new adapter class BasketItemAdapter is defined. It implements all the methods of the BasketItem and in each method makes necessary changes to the arguments and passes it to the new implementation as shown below.
== Example ==
<pre>
public Class BasketItemAdapter {
BasketItem newImplementation = new BasketItem();
void calculateCost(...) {
//make necessary modification
newImplementation.calculateCost(...);
}
}
</pre>

=Abstract Factory Pattern and Facade Pattern =

Abstract factory pattern provides a level of indirection that abstracts the creation of families of related or dependent objects without directly specifying their concrete classes. The “factory” object has the responsibility for providing creation services for the entire platform family. Clients never create platform objects directly, they ask the factory to do that for them.

This mechanism makes exchanging product families easy because the specific class of the factory object appears only once in the application - where it is instantiated. The application can wholesale replace the entire family of products simply by instantiating a different concrete instance of the abstract factory. Because the service provided by the factory object is so pervasive, it is routinely implemented as a Singleton. 

== Abstract Factory Example ==
[[File:Abstract.JPG|600px|center]]

The AbstractFactory defines the interface that all of the concrete factories will need to implement in order to product Products. ConcreteFactoryA and ConcreteFactoryB have both implemented this interface here, creating two seperate families of product. Meanwhile, AbstractProductA and AbstractProductB are interfaces for the different types of product. Each factory will create one of each of these AbstractProducts.

The Client deals with AbstractFactory, AbstractProductA and AbstractProductB. It doesn't know anything about the implementations. The actual implementation of AbstractFactory that the Client uses is determined at runtime.

As you can see, one of the main benefits of this pattern is that the client is totally decoupled from the concrete products. Also, new product families can be easily added into the system, by just adding in a new type of ConcreteFactory that implements AbstractFactory, and creating the specific Product implementations.

== Facade Pattern Example ==

[[File:Facade-wo.JPG|300px|thumb|left|Without a Facade, the client has to deal with the intricacies of the sub system.]]

[[File:Facade-w.JPG|300px|thumb|center|With a Facade, the complexities of sub system are unified into a single interface making it readily usable for the client.]]

Client contacts the Database to retrieve Company objects. It then retrieves Division objects from them and finally gains access to Employee objects.It uses four classes. With Facade, the Client is shielded from most of the classes. It uses the Database Facade to retrieve Employee objects directly.

=Mediator Pattern and Facade Pattern =
In Unix, permission to access system resources is managed at three levels of granularity: world, group, and owner. A group is a collection of users intended to model some functional affiliation. Each user on the system can be a member of one or more groups, and each group can have zero or more users assigned to it. Next figure shows three users that are assigned to all three groups. If we were to model this in software, we could decide to have User objects coupled to Group objects, and Group objects coupled to User objects. Then when changes occur, both classes and all their instances would be affected. An alternate approach would be to introduce “an additional level of indirection” - take the mapping of users to groups and groups to users, and make it an abstraction unto itself. This offers several advantages: Users and Groups are decoupled from one another, many mappings can easily be maintained and manipulated simultaneously, and the mapping abstraction can be extended in the future by defining derived classes. 

Partitioning a system into many objects generally enhances reusability, but proliferating interconnections between those objects tend to reduce it again. The mediator object: encapsulates all interconnections, acts as the hub of communication, is responsible for controlling and coordinating the interactions of its clients, and promotes loose coupling by keeping objects from referring to each other explicitly.

[[File:Mediator__1.gif]]

Colleagues (or peers) are not coupled to one another. Each talks to the Mediator, which in turn knows and conducts the orchestration of the others. The “many to many” mapping between colleagues that would otherwise exist, has been “promoted to full object status”. This new abstraction provides a locus of indirection where additional leverage can be hosted.

Mediator is similar to Facade in that it abstracts functionality of existing classes. Mediator abstracts/centralizes arbitrary communication between colleague objects, it routinely “adds value”, and it is known/referenced by the colleague objects (i.e. it defines a multidirectional protocol). In contrast, Facade defines a simpler interface to a subsystem, it doesn’t add new functionality, and it is not known by the subsystem classes (i.e. it defines a unidirectional protocol where it makes requests of the subsystem classes but not vice versa).

CSC/ECE 517 Fall 2012/ch2b 2w42 aa

2012-11-20T00:27:25Z

Aasawa: /* Facade Pattern Example */

=Introduction =

==Facade Pattern==
Intent 
* Provide a unified interface to a set of interfaces in a subsystem. 
* Wrap a complicated subsystem with a simpler interface. 

Facade discusses encapsulating a complex subsystem within a single interface object. This reduces the learning curve necessary to successfully leverage the subsystem. It also promotes decoupling the subsystem from its potentially many clients. On the other hand, if the Facade is the only access point for the subsystem, it will limit the features and flexibility that “power users” may need. The Facade object should be a fairly simple advocate or facilitator. It should not become an all-knowing oracle or “god” object. 

== Adapter Pattern ==

Intent 
* Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn’t otherwise because of incompatible interfaces. 
* Wrap an existing class with a new interface. 
* Impedance match an old component to a new system. 

Convert the interface of a class into another interface clients expect. Adapter lets classes worktogether that couldn't otherwise because of incompatible interfaces.

==Abstract Factory Pattern==

Intent 
* Provide an interface for creating families of related or dependent objects without specifying their concrete classes. 
* A hierarchy that encapsulates: many possible “platforms”, and the construction of a suite of “products”. 
* The new operator considered harmful. 

If an application is to be portable, it needs to encapsulate platform dependencies. These “platforms” might include: windowing system, operating system, database, etc. Too often, this encapsulatation is not engineered in advance, and lots of #ifdef case statements with options for all currently supported platforms begin to procreate like rabbits throughout the code. 

==Mediator Pattern==
Intent 

* Define an object that encapsulates how a set of objects interact. Mediator promotes loose coupling by keeping objects from referring to each other explicitly, and it lets you vary their interaction independently.
* Design an intermediary to decouple many peers.
* Promote the many-to-many relationships between interacting peers to “full object status”.

=Facade Pattern =

==Non-Software examples==
In most of the Pizza centers, orders will be given through phone calls with the customer interacting with the Customer service representative. In this case, consumers do not have access to the Billing system, Kitchen and delivery department. The customer service representative acts as an interface and interacts with each of the departments involved in the transaction and ensures that Pizzas are delivered to the consumer. Customer Service representative corresponds to the facade. Individual departments involved in the transaction correspond to Sub-systems.

==Software examples==
Web Service Facade Solution Architecture provides an example for Facade design pattern. In this architectural solution, instead of rewriting legacy applications or customizing those with middleware to connect to other applications one by one, this solution helps create a "facade" for the legacy application. Other applications are easily "plugged into" this facade. By modeling a legacy application into its basic functions of create, read, update, and delete and then exposing these functions as Web methods, the Web service facade solution allows other applications to access legacy data by making use of common Web services through standardized protocols. In this way, Facade decouples layers so that they do not depend on each other which can make it easier to develop, to use and to promote code re-use.

== C# Example ==
using System;
using System.Collections.Generic; 
namespace DesignPatterns.Facade
{
public class OrderFacade
{
//Places an Order and Returns an Order ID
public int placeOrder(int CustomerID, List<BasketItem> Products)
{
Order anOrder = new Order();
OrderLine anOrderLine = new OrderLine();
Address DespatchAddress = Address.getCustomerDespatchAddress(CustomerID);
int OrderId = anOrder.requestOrderID();
anOrder.createOrder(OrderId, DespatchAddress);
anOrderLine.addOrderLinesToOrder(OrderId, Products);
return OrderId;
}
} 
//order class
public class Order
{
public int requestOrderID()
{
//Creates and Returns a Unique Order ID
} 
public void createOrder(int OrderId, Address DespatchAddress)
{
}
} 
//OrderLine Class
public class OrderLine
{
public void addOrderLinesToOrder(int OrderId, List<BasketItem> Products)
{
}
} 
//Public Customer
public class Address
{
public static Address getCustomerDespatchAddress(int CustomerID)
{
return new Address();
}
//Address properties
} 
public class BasketItem
{
//BasketItem Properties
}
}

=Adapter Pattern and Facade Pattern =

Adapter functions as a wrapper or modifier of an existing class. It provides a different or translated view of that class. 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. Reuse has always been painful and elusive. One reason has been the tribulation of designing something new, while reusing something old. There is always something not quite right between the old and the new. It may be physical dimensions or misalignment. It may be timing or synchronization. It may be unfortunate assumptions or competing standards. It is like the problem of inserting a new three-prong electrical plug in an old two-prong wall outlet – some kind of adapter or intermediary is necessary. 

Adapter is about creating an intermediary abstraction that translates, or maps, the old component to the new system. Clients call methods on the Adapter object which redirects them into calls to the legacy component. This strategy can be implemented either with inheritance or with aggregation. 

== Adapter Pattern Example ==
<pre>
interface Shape {
void draw(...);
}

Class LegacyLine {
void draw(..) { }
}

Class LegacyRectangle {
void draw(..) { }
}

Class Line implements Shape {
adapter = new LegacyLine();
void draw(...) {adapter.draw(...)}
}

Class Rectangle implements Shape {
adapter = new LegacyRectangle();
void draw(...) {adapter.draw(...)}
}
</pre>

In the example provided for the Facade pattern, the method placeOrder() uses the methods exposed by many other classes such as Order, OrderLine, Address etc to provide a high level view for the callers. The callers need not worry about the complexities in handling the sub-system. The users of the Class OrderFacade just invoke the method placeOrder() with the necessary arguments and rest of the process is taken care by placeOrder(). As can be seen in this case, a new method (placeOrder) was defined which has the logic and the necessary steps to handle all the sub-systems to create an order, create an id for the order, create a dispatch address etc.

In the example provided for the Adapter pattern, no new methods are defined. The existing method draw of LegacyRectangle is wrapped in a adapter class Rectangle. The methods in adapter classes does the necessary manipulations to the arguments and then passes to the original classes.

On similar lines, assume that the implementation and structure of BasketItem in Facade example needs to be changed. To handle such scenario, a new adapter class BasketItemAdapter is defined. It implements all the methods of the BasketItem and in each method makes necessary changes to the arguments and passes it to the new implementation as shown below.
== Example ==
<pre>
public Class BasketItemAdapter {
BasketItem newImplementation = new BasketItem();
void calculateCost(...) {
//make necessary modification
newImplementation.calculateCost(...);
}
}
</pre>

=Abstract Factory Pattern and Facade Pattern =

Abstract factory pattern provides a level of indirection that abstracts the creation of families of related or dependent objects without directly specifying their concrete classes. The “factory” object has the responsibility for providing creation services for the entire platform family. Clients never create platform objects directly, they ask the factory to do that for them.

This mechanism makes exchanging product families easy because the specific class of the factory object appears only once in the application - where it is instantiated. The application can wholesale replace the entire family of products simply by instantiating a different concrete instance of the abstract factory. Because the service provided by the factory object is so pervasive, it is routinely implemented as a Singleton. 

== Abstract Factory Example ==
[[File:Abstract.JPG|600px|center]]

The AbstractFactory defines the interface that all of the concrete factories will need to implement in order to product Products. ConcreteFactoryA and ConcreteFactoryB have both implemented this interface here, creating two seperate families of product. Meanwhile, AbstractProductA and AbstractProductB are interfaces for the different types of product. Each factory will create one of each of these AbstractProducts.

The Client deals with AbstractFactory, AbstractProductA and AbstractProductB. It doesn't know anything about the implementations. The actual implementation of AbstractFactory that the Client uses is determined at runtime.

As you can see, one of the main benefits of this pattern is that the client is totally decoupled from the concrete products. Also, new product families can be easily added into the system, by just adding in a new type of ConcreteFactory that implements AbstractFactory, and creating the specific Product implementations.

== Facade Pattern Example ==

[[File:Facade-wo.JPG|300px|thumb|center|Without a Facade]]

[[File:Facade-w.JPG|300px|thumb|center|With a Facade]]

Client contacts the Database to retrieve Company objects. It then retrieves Division objects from them and finally gains access to Employee objects.It uses four classes. With Facade, the Client is shielded from most of the classes. It uses the Database Facade to retrieve Employee objects directly.

=Mediator Pattern and Facade Pattern =
In Unix, permission to access system resources is managed at three levels of granularity: world, group, and owner. A group is a collection of users intended to model some functional affiliation. Each user on the system can be a member of one or more groups, and each group can have zero or more users assigned to it. Next figure shows three users that are assigned to all three groups. If we were to model this in software, we could decide to have User objects coupled to Group objects, and Group objects coupled to User objects. Then when changes occur, both classes and all their instances would be affected. An alternate approach would be to introduce “an additional level of indirection” - take the mapping of users to groups and groups to users, and make it an abstraction unto itself. This offers several advantages: Users and Groups are decoupled from one another, many mappings can easily be maintained and manipulated simultaneously, and the mapping abstraction can be extended in the future by defining derived classes. 

Partitioning a system into many objects generally enhances reusability, but proliferating interconnections between those objects tend to reduce it again. The mediator object: encapsulates all interconnections, acts as the hub of communication, is responsible for controlling and coordinating the interactions of its clients, and promotes loose coupling by keeping objects from referring to each other explicitly.

[[File:Mediator__1.gif]]

=Differences n similarities between Adapter and Facade=
1)In both the Facade and Adapter pattern we havepreexisting classes.

2)In the Facade, however, we do not have aninterface we must design to, as we do in the Adapter pattern.

3)We are not interested in polymorphic behavior in theFacade, while in the Adapter, We probably am.(There are times when we just need to design to aparticular API and therefore must use an Adapter)

4)In the case of the Facade pattern, the motivation isto simplify the interface. With the Adapter, whilesimpler is better,We are trying to design to anexisting interface and cannot simplify things even if a simpler interface were otherwise possible.

Bottom line
: A Facade simplifies an interface whilean Adapter converts the interface into a preexistinginterface.

CSC/ECE 517 Fall 2012/ch2b 2w42 aa

2012-11-20T00:11:49Z

Aasawa: /* Abstract Factory Pattern and Facade Pattern */

CSC/ECE 517 Fall 2012/ch2b 2w42 aa

2012-11-20T00:09:22Z

Aasawa: /* Facade Pattern Example */

CSC/ECE 517 Fall 2012/ch2b 2w42 aa

2012-11-20T00:07:14Z

Aasawa: /* Facade Pattern Example */

CSC/ECE 517 Fall 2012/ch2b 2w42 aa

2012-11-20T00:05:29Z

Aasawa: /* Software examples */

CSC/ECE 517 Fall 2012/ch2b 2w42 aa

2012-11-20T00:04:35Z

Aasawa: /* Abstract Factory Pattern and Facade Pattern */

CSC/ECE 517 Fall 2012/ch2b 2w42 aa

2012-11-20T00:03:43Z

Aasawa: /* Abstract Factory Pattern and Facade Pattern */

CSC/ECE 517 Fall 2012/ch2b 2w42 aa

2012-11-20T00:02:48Z

Aasawa: /* Abstract Factory Pattern and Facade Pattern */

CSC/ECE 517 Fall 2012/ch2b 2w42 aa

2012-11-20T00:01:13Z

Aasawa: /* Abstract Factory Pattern and Facade Pattern */

File:Abstract.JPG

2012-11-20T00:00:51Z

Aasawa:

CSC/ECE 517 Fall 2012/ch2b 2w42 aa

2012-11-19T03:15:17Z

Aasawa: /* C# Example of above VB code */

=Introduction =

==Facade Pattern==

Intent 
1) 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. 
2) Wrap a complicated subsystem with a simpler interface. 

Non-Software examples 
In most of the Pizza centers, orders will be given through phone calls with the customer interacting with the Customer service representative. In this case, consumers do not have access to the Billing system, Kitchen and delivery department. The customer service representative acts as an interface and interacts with each of the departments involved in the transaction and ensures that Pizzas are delivered to the consumer.

We can relate this non-software example against the facade design pattern in the following way:

Customer Service representative corresponds to the facade.
Individual departments involved in the transaction correspond to Sub-systems.
Another example we can consider is Emergency services. In the event of fire we just inform an Emergency Service operator. The emergency operator interacts with police, ambulance and fire services and dispatches them. Here the client is shielded from individual emergency services.

Software examples 
Web Service Facade Solution Architecture provides an example for Facade design pattern. In this architectural solution, instead of rewriting legacy applications or customizing those with middleware to connect to other applications one by one, this solution helps create a "facade" for the legacy application. Other applications are easily "plugged into" this facade. By modeling a legacy application into its basic functions of create, read, update, and delete and then exposing these functions as Web methods, the Web service facade solution allows other applications to access legacy data by making use of common Web services through standardized protocols. In this way, Facade decouples layers so that they do not depend on each other which can make it easier to develop, to use and to promote code re-use.

The JIT (Just in-Time) compilers that we use everyday to process the Dotnet code is a prime example of the facade pattern. JIT compiler performs several lower level functions before converting MSIL into native code, such as verifying whether Microsoft intermediate language (MSIL) code can access the memory locations, checking MSIL code is correctly generated because incorrect MSIL can lead to a violation of the type safety rules, etc.

[[File:Facade-wo.JPG|300px|thumb|center|Without a Facade, Client contacts the Database to retrieve Company objects. It then retrieves Division objects from them and finally gains access to Employee objects.It uses four classes.]]
[[File:Facade-w.JPG|300px|thumb|center|With a Facade, the Client is shielded from most of the classes. It uses the Database Facade to retrieve Employee objects directly.]]

== C# Example ==

using System;
using System.Collections.Generic; 
namespace Yanesh.DesignPatterns.Facade
{
public class OrderFacade
{
//Places an Order and Returns an Order ID
public int placeOrder(int CustomerID, List<BasketItem> Products)
{
Order anOrder = new Order();
OrderLine anOrderLine = new OrderLine();
Address DespatchAddress = Address.getCustomerDespatchAddress(CustomerID);
int OrderId = anOrder.requestOrderID();
anOrder.createOrder(OrderId, DespatchAddress);
anOrderLine.addOrderLinesToOrder(OrderId, Products);
return OrderId;
}
} 
//order class
public class Order
{
public int requestOrderID()
{
//Creates and Returns a Unique Order ID
} 
public void createOrder(int OrderId, Address DespatchAddress)
{
}
} 
//OrderLine Class
public class OrderLine
{
public void addOrderLinesToOrder(int OrderId, List<BasketItem> Products)
{
}
} 
//Public Customer
public class Address
{
public static Address getCustomerDespatchAddress(int CustomerID)
{
return new Address();
}
//Address properties
} 
public class BasketItem
{
//BasketItem Properties
}
}

Problem 
A segment of the client community needs a simplified interface to the overall functionality of a complex subsystem. 

Facade discusses encapsulating a complex subsystem within a single interface object. This reduces the learning curve necessary to successfully leverage the subsystem. It also promotes decoupling the subsystem from its potentially many clients. On the other hand, if the Facade is the only access point for the subsystem, it will limit the features and flexibility that “power users” may need. The Facade object should be a fairly simple advocate or facilitator. It should not become an all-knowing oracle or “god” object. 

==Abstract Factory Pattern==

Intent 
1) Provide an interface for creating families of related or dependent objects without specifying their concrete classes. 
2) A hierarchy that encapsulates: many possible “platforms”, and the construction of a suite of “products”. 
3) The new operator considered harmful. 

Problem 

If an application is to be portable, it needs to encapsulate platform dependencies. These “platforms” might include: windowing system, operating system, database, etc. Too often, this encapsulatation is not engineered in advance, and lots of #ifdef case statements with options for all currently supported platforms begin to procreate like rabbits throughout the code. 

Discussion 

Provide a level of indirection that abstracts the creation of families of related or dependent objects without directly specifying their concrete classes. The “factory” object has the responsibility for providing creation services for the entire platform family. Clients never create platform objects directly, they ask the factory to do that for them.

This mechanism makes exchanging product families easy because the specific class of the factory object appears only once in the application - where it is instantiated. The application can wholesale replace the entire family of products simply by instantiating a different concrete instance of the abstract factory. Because the service provided by the factory object is so pervasive, it is routinely implemented as a Singleton. 

== Adapter Pattern ==
Convert the interface of a class into another interface clients expect. Adapter lets classes worktogether that couldn't otherwise because of incompatible interfaces.

Intent 
1)Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn’t otherwise because of incompatible interfaces. 
2)Wrap an existing class with a new interface. 
3)Impedance match an old component to a new system. 

Two types of adapter patterns 
1)Object Adapter pattern— relies on one object(the adapting object) containing another (theadapted object). 
2)Class Adapter pattern— implemented withmultiple inheritance

Problem 
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.

Discussion 
Reuse has always been painful and elusive. One reason has been the tribulation of designing something new, while reusing something old. There is always something not quite right between the old and the new. It may be physical dimensions or misalignment. It may be timing or synchronization. It may be unfortunate assumptions or competing standards.
 
It is like the problem of inserting a new three-prong electrical plug in an old two-prong wall outlet – some kind of adapter or intermediary is necessary.

Adapter is about creating an intermediary abstraction that translates, or maps, the old component to the new system. Clients call methods on the Adapter object which redirects them into calls to the legacy component. This strategy can be implemented either with inheritance or with aggregation.

Adapter functions as a wrapper or modifier of an existing class. It provides a different or translated view of that class.

==Mediator Pattern==

== Differences n similarities between Adapter and Facade ==
1)In both the Facade and Adapter pattern we havepreexisting classes.

2)In the Facade, however, we do not have aninterface we must design to, as we do in the Adapter pattern.

3)We are not interested in polymorphic behavior in theFacade, while in the Adapter, We probably am.(There are times when we just need to design to aparticular API and therefore must use an Adapter)

4)In the case of the Facade pattern, the motivation isto simplify the interface. With the Adapter, whilesimpler is better,We are trying to design to anexisting interface and cannot simplify things even if a simpler interface were otherwise possible.

Bottom line
: A Facade simplifies an interface whilean Adapter converts the interface into a preexistinginterface.

CSC/ECE 517 Fall 2012/ch2b 2w42 aa

2012-11-19T03:15:02Z

Aasawa: /* Facade Pattern */

=Introduction =

==Facade Pattern==

Intent 
1) 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. 
2) Wrap a complicated subsystem with a simpler interface. 

Non-Software examples 
In most of the Pizza centers, orders will be given through phone calls with the customer interacting with the Customer service representative. In this case, consumers do not have access to the Billing system, Kitchen and delivery department. The customer service representative acts as an interface and interacts with each of the departments involved in the transaction and ensures that Pizzas are delivered to the consumer.

We can relate this non-software example against the facade design pattern in the following way:

Customer Service representative corresponds to the facade.
Individual departments involved in the transaction correspond to Sub-systems.
Another example we can consider is Emergency services. In the event of fire we just inform an Emergency Service operator. The emergency operator interacts with police, ambulance and fire services and dispatches them. Here the client is shielded from individual emergency services.

Software examples 
Web Service Facade Solution Architecture provides an example for Facade design pattern. In this architectural solution, instead of rewriting legacy applications or customizing those with middleware to connect to other applications one by one, this solution helps create a "facade" for the legacy application. Other applications are easily "plugged into" this facade. By modeling a legacy application into its basic functions of create, read, update, and delete and then exposing these functions as Web methods, the Web service facade solution allows other applications to access legacy data by making use of common Web services through standardized protocols. In this way, Facade decouples layers so that they do not depend on each other which can make it easier to develop, to use and to promote code re-use.

The JIT (Just in-Time) compilers that we use everyday to process the Dotnet code is a prime example of the facade pattern. JIT compiler performs several lower level functions before converting MSIL into native code, such as verifying whether Microsoft intermediate language (MSIL) code can access the memory locations, checking MSIL code is correctly generated because incorrect MSIL can lead to a violation of the type safety rules, etc.

[[File:Facade-wo.JPG|300px|thumb|center|Without a Facade, Client contacts the Database to retrieve Company objects. It then retrieves Division objects from them and finally gains access to Employee objects.It uses four classes.]]
[[File:Facade-w.JPG|300px|thumb|center|With a Facade, the Client is shielded from most of the classes. It uses the Database Facade to retrieve Employee objects directly.]]

== C# Example of above VB code ==

using System;
using System.Collections.Generic; 
namespace Yanesh.DesignPatterns.Facade
{
public class OrderFacade
{
//Places an Order and Returns an Order ID
public int placeOrder(int CustomerID, List<BasketItem> Products)
{
Order anOrder = new Order();
OrderLine anOrderLine = new OrderLine();
Address DespatchAddress = Address.getCustomerDespatchAddress(CustomerID);
int OrderId = anOrder.requestOrderID();
anOrder.createOrder(OrderId, DespatchAddress);
anOrderLine.addOrderLinesToOrder(OrderId, Products);
return OrderId;
}
} 
//order class
public class Order
{
public int requestOrderID()
{
//Creates and Returns a Unique Order ID
} 
public void createOrder(int OrderId, Address DespatchAddress)
{
}
} 
//OrderLine Class
public class OrderLine
{
public void addOrderLinesToOrder(int OrderId, List<BasketItem> Products)
{
}
} 
//Public Customer
public class Address
{
public static Address getCustomerDespatchAddress(int CustomerID)
{
return new Address();
}
//Address properties
} 
public class BasketItem
{
//BasketItem Properties
}
}

Problem 
A segment of the client community needs a simplified interface to the overall functionality of a complex subsystem. 

Facade discusses encapsulating a complex subsystem within a single interface object. This reduces the learning curve necessary to successfully leverage the subsystem. It also promotes decoupling the subsystem from its potentially many clients. On the other hand, if the Facade is the only access point for the subsystem, it will limit the features and flexibility that “power users” may need. The Facade object should be a fairly simple advocate or facilitator. It should not become an all-knowing oracle or “god” object. 

==Abstract Factory Pattern==

Intent 
1) Provide an interface for creating families of related or dependent objects without specifying their concrete classes. 
2) A hierarchy that encapsulates: many possible “platforms”, and the construction of a suite of “products”. 
3) The new operator considered harmful. 

Problem 

If an application is to be portable, it needs to encapsulate platform dependencies. These “platforms” might include: windowing system, operating system, database, etc. Too often, this encapsulatation is not engineered in advance, and lots of #ifdef case statements with options for all currently supported platforms begin to procreate like rabbits throughout the code. 

Discussion 

Provide a level of indirection that abstracts the creation of families of related or dependent objects without directly specifying their concrete classes. The “factory” object has the responsibility for providing creation services for the entire platform family. Clients never create platform objects directly, they ask the factory to do that for them.

This mechanism makes exchanging product families easy because the specific class of the factory object appears only once in the application - where it is instantiated. The application can wholesale replace the entire family of products simply by instantiating a different concrete instance of the abstract factory. Because the service provided by the factory object is so pervasive, it is routinely implemented as a Singleton. 

== Adapter Pattern ==
Convert the interface of a class into another interface clients expect. Adapter lets classes worktogether that couldn't otherwise because of incompatible interfaces.

Intent 
1)Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn’t otherwise because of incompatible interfaces. 
2)Wrap an existing class with a new interface. 
3)Impedance match an old component to a new system. 

Two types of adapter patterns 
1)Object Adapter pattern— relies on one object(the adapting object) containing another (theadapted object). 
2)Class Adapter pattern— implemented withmultiple inheritance

Problem 
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.

Discussion 
Reuse has always been painful and elusive. One reason has been the tribulation of designing something new, while reusing something old. There is always something not quite right between the old and the new. It may be physical dimensions or misalignment. It may be timing or synchronization. It may be unfortunate assumptions or competing standards.
 
It is like the problem of inserting a new three-prong electrical plug in an old two-prong wall outlet – some kind of adapter or intermediary is necessary.

Adapter is about creating an intermediary abstraction that translates, or maps, the old component to the new system. Clients call methods on the Adapter object which redirects them into calls to the legacy component. This strategy can be implemented either with inheritance or with aggregation.

Adapter functions as a wrapper or modifier of an existing class. It provides a different or translated view of that class.

==Mediator Pattern==

== Differences n similarities between Adapter and Facade ==
1)In both the Facade and Adapter pattern we havepreexisting classes.

2)In the Facade, however, we do not have aninterface we must design to, as we do in the Adapter pattern.

3)We are not interested in polymorphic behavior in theFacade, while in the Adapter, We probably am.(There are times when we just need to design to aparticular API and therefore must use an Adapter)

4)In the case of the Facade pattern, the motivation isto simplify the interface. With the Adapter, whilesimpler is better,We are trying to design to anexisting interface and cannot simplify things even if a simpler interface were otherwise possible.

Bottom line
: A Facade simplifies an interface whilean Adapter converts the interface into a preexistinginterface.

CSC/ECE 517 Fall 2012/ch2b 2w42 aa

2012-11-19T03:14:14Z

Aasawa: /* Facade Pattern */

=Introduction =

==Facade Pattern==

Intent 
1) 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. 
2) Wrap a complicated subsystem with a simpler interface. 

Non-Software examples 
In most of the Pizza centers, orders will be given through phone calls with the customer interacting with the Customer service representative. In this case, consumers do not have access to the Billing system, Kitchen and delivery department. The customer service representative acts as an interface and interacts with each of the departments involved in the transaction and ensures that Pizzas are delivered to the consumer.

We can relate this non-software example against the facade design pattern in the following way:

Customer Service representative corresponds to the facade.
Individual departments involved in the transaction correspond to Sub-systems.
Another example we can consider is Emergency services. In the event of fire we just inform an Emergency Service operator. The emergency operator interacts with police, ambulance and fire services and dispatches them. Here the client is shielded from individual emergency services.

Software examples 
Web Service Facade Solution Architecture provides an example for Facade design pattern. In this architectural solution, instead of rewriting legacy applications or customizing those with middleware to connect to other applications one by one, this solution helps create a "facade" for the legacy application. Other applications are easily "plugged into" this facade. By modeling a legacy application into its basic functions of create, read, update, and delete and then exposing these functions as Web methods, the Web service facade solution allows other applications to access legacy data by making use of common Web services through standardized protocols. In this way, Facade decouples layers so that they do not depend on each other which can make it easier to develop, to use and to promote code re-use.

The JIT (Just in-Time) compilers that we use everyday to process the Dotnet code is a prime example of the facade pattern. JIT compiler performs several lower level functions before converting MSIL into native code, such as verifying whether Microsoft intermediate language (MSIL) code can access the memory locations, checking MSIL code is correctly generated because incorrect MSIL can lead to a violation of the type safety rules, etc.

[[File:Facade-wo.JPG|300px|thumb|center|Without a Facade, Client contacts the Database to retrieve Company objects. It then retrieves Division objects from them and finally gains access to Employee objects.It uses four classes.]]
[[File:Facade-w.JPG|300px|thumb|center|With a Facade, the Client is shielded from most of the classes. It uses the Database Facade to retrieve Employee objects directly.]]

using System;
using System.Collections.Generic; 
namespace Yanesh.DesignPatterns.Facade
{
public class OrderFacade
{
//Places an Order and Returns an Order ID
public int placeOrder(int CustomerID, List<BasketItem> Products)
{
Order anOrder = new Order();
OrderLine anOrderLine = new OrderLine();
Address DespatchAddress = Address.getCustomerDespatchAddress(CustomerID);
int OrderId = anOrder.requestOrderID();
anOrder.createOrder(OrderId, DespatchAddress);
anOrderLine.addOrderLinesToOrder(OrderId, Products);
return OrderId;
}
} 
//order class
public class Order
{
public int requestOrderID()
{
//Creates and Returns a Unique Order ID
} 
public void createOrder(int OrderId, Address DespatchAddress)
{
}
} 
//OrderLine Class
public class OrderLine
{
public void addOrderLinesToOrder(int OrderId, List<BasketItem> Products)
{
}
} 
//Public Customer
public class Address
{
public static Address getCustomerDespatchAddress(int CustomerID)
{
return new Address();
}
//Address properties
} 
public class BasketItem
{
//BasketItem Properties
}
}

Problem 
A segment of the client community needs a simplified interface to the overall functionality of a complex subsystem. 

Facade discusses encapsulating a complex subsystem within a single interface object. This reduces the learning curve necessary to successfully leverage the subsystem. It also promotes decoupling the subsystem from its potentially many clients. On the other hand, if the Facade is the only access point for the subsystem, it will limit the features and flexibility that “power users” may need. The Facade object should be a fairly simple advocate or facilitator. It should not become an all-knowing oracle or “god” object. 

==Abstract Factory Pattern==

Intent 
1) Provide an interface for creating families of related or dependent objects without specifying their concrete classes. 
2) A hierarchy that encapsulates: many possible “platforms”, and the construction of a suite of “products”. 
3) The new operator considered harmful. 

Problem 

If an application is to be portable, it needs to encapsulate platform dependencies. These “platforms” might include: windowing system, operating system, database, etc. Too often, this encapsulatation is not engineered in advance, and lots of #ifdef case statements with options for all currently supported platforms begin to procreate like rabbits throughout the code. 

Discussion 

Provide a level of indirection that abstracts the creation of families of related or dependent objects without directly specifying their concrete classes. The “factory” object has the responsibility for providing creation services for the entire platform family. Clients never create platform objects directly, they ask the factory to do that for them.

This mechanism makes exchanging product families easy because the specific class of the factory object appears only once in the application - where it is instantiated. The application can wholesale replace the entire family of products simply by instantiating a different concrete instance of the abstract factory. Because the service provided by the factory object is so pervasive, it is routinely implemented as a Singleton. 

== Adapter Pattern ==
Convert the interface of a class into another interface clients expect. Adapter lets classes worktogether that couldn't otherwise because of incompatible interfaces.

Intent 
1)Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn’t otherwise because of incompatible interfaces. 
2)Wrap an existing class with a new interface. 
3)Impedance match an old component to a new system. 

Two types of adapter patterns 
1)Object Adapter pattern— relies on one object(the adapting object) containing another (theadapted object). 
2)Class Adapter pattern— implemented withmultiple inheritance

Problem 
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.

Discussion 
Reuse has always been painful and elusive. One reason has been the tribulation of designing something new, while reusing something old. There is always something not quite right between the old and the new. It may be physical dimensions or misalignment. It may be timing or synchronization. It may be unfortunate assumptions or competing standards.
 
It is like the problem of inserting a new three-prong electrical plug in an old two-prong wall outlet – some kind of adapter or intermediary is necessary.

Adapter is about creating an intermediary abstraction that translates, or maps, the old component to the new system. Clients call methods on the Adapter object which redirects them into calls to the legacy component. This strategy can be implemented either with inheritance or with aggregation.

Adapter functions as a wrapper or modifier of an existing class. It provides a different or translated view of that class.

==Mediator Pattern==

== Differences n similarities between Adapter and Facade ==
1)In both the Facade and Adapter pattern we havepreexisting classes.

2)In the Facade, however, we do not have aninterface we must design to, as we do in the Adapter pattern.

3)We are not interested in polymorphic behavior in theFacade, while in the Adapter, We probably am.(There are times when we just need to design to aparticular API and therefore must use an Adapter)

4)In the case of the Facade pattern, the motivation isto simplify the interface. With the Adapter, whilesimpler is better,We are trying to design to anexisting interface and cannot simplify things even if a simpler interface were otherwise possible.

Bottom line
: A Facade simplifies an interface whilean Adapter converts the interface into a preexistinginterface.

CSC/ECE 517 Fall 2012/ch2b 2w42 aa

2012-11-19T03:13:49Z

Aasawa: /* Facade Pattern */

=Introduction =

==Facade Pattern==

Intent 
1) 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. 
2) Wrap a complicated subsystem with a simpler interface. 

Non-Software examples 
In most of the Pizza centers, orders will be given through phone calls with the customer interacting with the Customer service representative. In this case, consumers do not have access to the Billing system, Kitchen and delivery department. The customer service representative acts as an interface and interacts with each of the departments involved in the transaction and ensures that Pizzas are delivered to the consumer.

We can relate this non-software example against the facade design pattern in the following way:

Customer Service representative corresponds to the facade.
Individual departments involved in the transaction correspond to Sub-systems.
Another example we can consider is Emergency services. In the event of fire we just inform an Emergency Service operator. The emergency operator interacts with police, ambulance and fire services and dispatches them. Here the client is shielded from individual emergency services.

Software examples 
Web Service Facade Solution Architecture provides an example for Facade design pattern. In this architectural solution, instead of rewriting legacy applications or customizing those with middleware to connect to other applications one by one, this solution helps create a "facade" for the legacy application. Other applications are easily "plugged into" this facade. By modeling a legacy application into its basic functions of create, read, update, and delete and then exposing these functions as Web methods, the Web service facade solution allows other applications to access legacy data by making use of common Web services through standardized protocols. In this way, Facade decouples layers so that they do not depend on each other which can make it easier to develop, to use and to promote code re-use.

The JIT (Just in-Time) compilers that we use everyday to process the Dotnet code is a prime example of the facade pattern. JIT compiler performs several lower level functions before converting MSIL into native code, such as verifying whether Microsoft intermediate language (MSIL) code can access the memory locations, checking MSIL code is correctly generated because incorrect MSIL can lead to a violation of the type safety rules, etc.

[[File:Facade-wo.JPG|300px|thumb|center|Without a Facade, Client contacts the Database to retrieve Company objects. It then retrieves Division objects from them and finally gains access to Employee objects.It uses four classes.]]
[[File:Facade-w.JPG|300px|thumb|center|With a Facade, the Client is shielded from most of the classes. It uses the Database Facade to retrieve Employee objects directly.]]

using System;
using System.Collections.Generic; 
namespace Yanesh.DesignPatterns.Facade
{
public class OrderFacade
{
//Places an Order and Returns an Order ID
public int placeOrder(int CustomerID, List<BasketItem> Products)
{
Order anOrder = new Order();
OrderLine anOrderLine = new OrderLine();
Address DespatchAddress = Address.getCustomerDespatchAddress(CustomerID);
int OrderId = anOrder.requestOrderID();

anOrder.createOrder(OrderId, DespatchAddress);
anOrderLine.addOrderLinesToOrder(OrderId, Products);

return OrderId;
}
} 
//order class
public class Order
{
public int requestOrderID()
{
//Creates and Returns a Unique Order ID
} 
public void createOrder(int OrderId, Address DespatchAddress)
{
}
} 
//OrderLine Class
public class OrderLine
{
public void addOrderLinesToOrder(int OrderId, List<BasketItem> Products)
{
}
} 
//Public Customer
public class Address
{
public static Address getCustomerDespatchAddress(int CustomerID)
{
return new Address();
}
//Address properties
} 
public class BasketItem
{
//BasketItem Properties
}
}

Problem 
A segment of the client community needs a simplified interface to the overall functionality of a complex subsystem. 

Facade discusses encapsulating a complex subsystem within a single interface object. This reduces the learning curve necessary to successfully leverage the subsystem. It also promotes decoupling the subsystem from its potentially many clients. On the other hand, if the Facade is the only access point for the subsystem, it will limit the features and flexibility that “power users” may need. The Facade object should be a fairly simple advocate or facilitator. It should not become an all-knowing oracle or “god” object. 

==Abstract Factory Pattern==

Intent 
1) Provide an interface for creating families of related or dependent objects without specifying their concrete classes. 
2) A hierarchy that encapsulates: many possible “platforms”, and the construction of a suite of “products”. 
3) The new operator considered harmful. 

Problem 

If an application is to be portable, it needs to encapsulate platform dependencies. These “platforms” might include: windowing system, operating system, database, etc. Too often, this encapsulatation is not engineered in advance, and lots of #ifdef case statements with options for all currently supported platforms begin to procreate like rabbits throughout the code. 

Discussion 

Provide a level of indirection that abstracts the creation of families of related or dependent objects without directly specifying their concrete classes. The “factory” object has the responsibility for providing creation services for the entire platform family. Clients never create platform objects directly, they ask the factory to do that for them.

This mechanism makes exchanging product families easy because the specific class of the factory object appears only once in the application - where it is instantiated. The application can wholesale replace the entire family of products simply by instantiating a different concrete instance of the abstract factory. Because the service provided by the factory object is so pervasive, it is routinely implemented as a Singleton. 

== Adapter Pattern ==
Convert the interface of a class into another interface clients expect. Adapter lets classes worktogether that couldn't otherwise because of incompatible interfaces.

Intent 
1)Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn’t otherwise because of incompatible interfaces. 
2)Wrap an existing class with a new interface. 
3)Impedance match an old component to a new system. 

Two types of adapter patterns 
1)Object Adapter pattern— relies on one object(the adapting object) containing another (theadapted object). 
2)Class Adapter pattern— implemented withmultiple inheritance

Problem 
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.

Discussion 
Reuse has always been painful and elusive. One reason has been the tribulation of designing something new, while reusing something old. There is always something not quite right between the old and the new. It may be physical dimensions or misalignment. It may be timing or synchronization. It may be unfortunate assumptions or competing standards.
 
It is like the problem of inserting a new three-prong electrical plug in an old two-prong wall outlet – some kind of adapter or intermediary is necessary.

Adapter is about creating an intermediary abstraction that translates, or maps, the old component to the new system. Clients call methods on the Adapter object which redirects them into calls to the legacy component. This strategy can be implemented either with inheritance or with aggregation.

Adapter functions as a wrapper or modifier of an existing class. It provides a different or translated view of that class.

==Mediator Pattern==

== Differences n similarities between Adapter and Facade ==
1)In both the Facade and Adapter pattern we havepreexisting classes.

2)In the Facade, however, we do not have aninterface we must design to, as we do in the Adapter pattern.

3)We are not interested in polymorphic behavior in theFacade, while in the Adapter, We probably am.(There are times when we just need to design to aparticular API and therefore must use an Adapter)

4)In the case of the Facade pattern, the motivation isto simplify the interface. With the Adapter, whilesimpler is better,We are trying to design to anexisting interface and cannot simplify things even if a simpler interface were otherwise possible.

Bottom line
: A Facade simplifies an interface whilean Adapter converts the interface into a preexistinginterface.

CSC/ECE 517 Fall 2012/ch2b 2w42 aa

2012-11-19T03:10:31Z

Aasawa: /* Facade Pattern */

=Introduction =

==Facade Pattern==

Intent 
1) 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. 
2) Wrap a complicated subsystem with a simpler interface. 

Non-Software examples 
In most of the Pizza centers, orders will be given through phone calls with the customer interacting with the Customer service representative. In this case, consumers do not have access to the Billing system, Kitchen and delivery department. The customer service representative acts as an interface and interacts with each of the departments involved in the transaction and ensures that Pizzas are delivered to the consumer.

We can relate this non-software example against the facade design pattern in the following way:

Customer Service representative corresponds to the facade.
Individual departments involved in the transaction correspond to Sub-systems.
Another example we can consider is Emergency services. In the event of fire we just inform an Emergency Service operator. The emergency operator interacts with police, ambulance and fire services and dispatches them. Here the client is shielded from individual emergency services.

Software examples 
Web Service Facade Solution Architecture provides an example for Facade design pattern. In this architectural solution, instead of rewriting legacy applications or customizing those with middleware to connect to other applications one by one, this solution helps create a "facade" for the legacy application. Other applications are easily "plugged into" this facade. By modeling a legacy application into its basic functions of create, read, update, and delete and then exposing these functions as Web methods, the Web service facade solution allows other applications to access legacy data by making use of common Web services through standardized protocols. In this way, Facade decouples layers so that they do not depend on each other which can make it easier to develop, to use and to promote code re-use.

The JIT (Just in-Time) compilers that we use everyday to process the Dotnet code is a prime example of the facade pattern. JIT compiler performs several lower level functions before converting MSIL into native code, such as verifying whether Microsoft intermediate language (MSIL) code can access the memory locations, checking MSIL code is correctly generated because incorrect MSIL can lead to a violation of the type safety rules, etc.

[[File:Facade-wo.JPG|300px|thumb|center|Without a Facade, Client contacts the Database to retrieve Company objects. It then retrieves Division objects from them and finally gains access to Employee objects.It uses four classes.]]
[[File:Facade-w.JPG|300px|thumb|center|With a Facade, the Client is shielded from most of the classes. It uses the Database Facade to retrieve Employee objects directly.]]

' This code would be run at page code behind level
Dim aPayment As IPayment
Dim paymentType As String ' this value would be populated elsewhere 
aPayment = PaymentFactory.getPayment(paymentType)
aPayment.takePayment(10.5) 
' The payment interface
Public Interface IPayment
Sub takePayment(ByVal Amount As Double)
End Interface 
' PayPal Payment class that implements the IPayment Interface
Public Class PayPalPayment
Implements IPayment
Public Sub takePayment(ByVal Amount As Double) Implements IPayment.takePayment
' Code to take payment via PayPal merchant
End Sub
End Class 
' Credit Card Payment class that implements the IPayment Interface
Public Class CreditCardPayment
Implements IPayment
Public Sub takePayment(ByVal Amount As Double) Implements IPayment.takePayment
' Code to take payment via a credit card
End Sub
End Class 
' Adapter Class to ensure third party code implements IPayment
Public Class ThirdPartyPaymentAdapter
Inherits ThirdPartyPayment
Implements IPayment
Public Sub takePayment(ByVal Amount As Double) Implements IPayment.takePayment
' This methods calls the actual thrid party code.
' If we couldn't inherit we could instantiate the object here or in the
' constructor method.
MyBase.makeTransasction(Amount, False)
End Sub
End Class 
' Third Party Payment Class
Public Class ThirdPartyPayment
Public Sub makeTransasction(ByVal amount As Double, ByVal refund As Boolean)
' Third party code...
End Sub
End Class 
' Factory Class to return Concrete Payment object
Public Class PaymentFactory
Public Shared Function getPayment(ByVal PaymentType As String) As IPayment
Select Case PaymentType
Case "CreditCard"
Return New CreditCardPayment
Case "PayPal"
Return New PayPalPayment
Case Else
Return New ThirdPartyPaymentAdapter
End Select
End Function
End Class

Problem 
A segment of the client community needs a simplified interface to the overall functionality of a complex subsystem. 

Facade discusses encapsulating a complex subsystem within a single interface object. This reduces the learning curve necessary to successfully leverage the subsystem. It also promotes decoupling the subsystem from its potentially many clients. On the other hand, if the Facade is the only access point for the subsystem, it will limit the features and flexibility that “power users” may need. The Facade object should be a fairly simple advocate or facilitator. It should not become an all-knowing oracle or “god” object. 

==Abstract Factory Pattern==

Intent 
1) Provide an interface for creating families of related or dependent objects without specifying their concrete classes. 
2) A hierarchy that encapsulates: many possible “platforms”, and the construction of a suite of “products”. 
3) The new operator considered harmful. 

Problem 

If an application is to be portable, it needs to encapsulate platform dependencies. These “platforms” might include: windowing system, operating system, database, etc. Too often, this encapsulatation is not engineered in advance, and lots of #ifdef case statements with options for all currently supported platforms begin to procreate like rabbits throughout the code. 

Discussion 

Provide a level of indirection that abstracts the creation of families of related or dependent objects without directly specifying their concrete classes. The “factory” object has the responsibility for providing creation services for the entire platform family. Clients never create platform objects directly, they ask the factory to do that for them.

This mechanism makes exchanging product families easy because the specific class of the factory object appears only once in the application - where it is instantiated. The application can wholesale replace the entire family of products simply by instantiating a different concrete instance of the abstract factory. Because the service provided by the factory object is so pervasive, it is routinely implemented as a Singleton. 

== Adapter Pattern ==
Convert the interface of a class into another interface clients expect. Adapter lets classes worktogether that couldn't otherwise because of incompatible interfaces.

Intent 
1)Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn’t otherwise because of incompatible interfaces. 
2)Wrap an existing class with a new interface. 
3)Impedance match an old component to a new system. 

Two types of adapter patterns 
1)Object Adapter pattern— relies on one object(the adapting object) containing another (theadapted object). 
2)Class Adapter pattern— implemented withmultiple inheritance

Problem 
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.

Discussion 
Reuse has always been painful and elusive. One reason has been the tribulation of designing something new, while reusing something old. There is always something not quite right between the old and the new. It may be physical dimensions or misalignment. It may be timing or synchronization. It may be unfortunate assumptions or competing standards.
 
It is like the problem of inserting a new three-prong electrical plug in an old two-prong wall outlet – some kind of adapter or intermediary is necessary.

Adapter is about creating an intermediary abstraction that translates, or maps, the old component to the new system. Clients call methods on the Adapter object which redirects them into calls to the legacy component. This strategy can be implemented either with inheritance or with aggregation.

Adapter functions as a wrapper or modifier of an existing class. It provides a different or translated view of that class.

==Mediator Pattern==

== Differences n similarities between Adapter and Facade ==
1)In both the Facade and Adapter pattern we havepreexisting classes.

2)In the Facade, however, we do not have aninterface we must design to, as we do in the Adapter pattern.

3)We are not interested in polymorphic behavior in theFacade, while in the Adapter, We probably am.(There are times when we just need to design to aparticular API and therefore must use an Adapter)

4)In the case of the Facade pattern, the motivation isto simplify the interface. With the Adapter, whilesimpler is better,We are trying to design to anexisting interface and cannot simplify things even if a simpler interface were otherwise possible.

Bottom line
: A Facade simplifies an interface whilean Adapter converts the interface into a preexistinginterface.

CSC/ECE 517 Fall 2012/ch2b 2w42 aa

2012-11-19T02:57:37Z

Aasawa: /* Facade Pattern */

=Introduction =

==Facade Pattern==

Intent 
1) 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. 
2) Wrap a complicated subsystem with a simpler interface. 

Non-Software examples 
In most of the Pizza centers, orders will be given through phone calls with the customer interacting with the Customer service representative. In this case, consumers do not have access to the Billing system, Kitchen and delivery department. The customer service representative acts as an interface and interacts with each of the departments involved in the transaction and ensures that Pizzas are delivered to the consumer.

We can relate this non-software example against the facade design pattern in the following way:

Customer Service representative corresponds to the facade.
Individual departments involved in the transaction correspond to Sub-systems.
Another example we can consider is Emergency services. In the event of fire we just inform an Emergency Service operator. The emergency operator interacts with police, ambulance and fire services and dispatches them. Here the client is shielded from individual emergency services.

Software examples 
Web Service Facade Solution Architecture provides an example for Facade design pattern. In this architectural solution, instead of rewriting legacy applications or customizing those with middleware to connect to other applications one by one, this solution helps create a "facade" for the legacy application. Other applications are easily "plugged into" this facade. By modeling a legacy application into its basic functions of create, read, update, and delete and then exposing these functions as Web methods, the Web service facade solution allows other applications to access legacy data by making use of common Web services through standardized protocols. In this way, Facade decouples layers so that they do not depend on each other which can make it easier to develop, to use and to promote code re-use.

The JIT (Just in-Time) compilers that we use everyday to process the Dotnet code is a prime example of the facade pattern. JIT compiler performs several lower level functions before converting MSIL into native code, such as verifying whether Microsoft intermediate language (MSIL) code can access the memory locations, checking MSIL code is correctly generated because incorrect MSIL can lead to a violation of the type safety rules, etc.

[[File:Facade-wo.JPG|300px|thumb|center|Without a Facade, Client contacts the Database to retrieve Company objects. It then retrieves Division objects from them and finally gains access to Employee objects.It uses four classes.]]
[[File:Facade-w.JPG|300px|thumb|center|With a Facade, the Client is shielded from most of the classes. It uses the Database Facade to retrieve Employee objects directly.]]

Problem 
A segment of the client community needs a simplified interface to the overall functionality of a complex subsystem. 

Facade discusses encapsulating a complex subsystem within a single interface object. This reduces the learning curve necessary to successfully leverage the subsystem. It also promotes decoupling the subsystem from its potentially many clients. On the other hand, if the Facade is the only access point for the subsystem, it will limit the features and flexibility that “power users” may need. The Facade object should be a fairly simple advocate or facilitator. It should not become an all-knowing oracle or “god” object. 

==Abstract Factory Pattern==

Intent 
1) Provide an interface for creating families of related or dependent objects without specifying their concrete classes. 
2) A hierarchy that encapsulates: many possible “platforms”, and the construction of a suite of “products”. 
3) The new operator considered harmful. 

Problem 

If an application is to be portable, it needs to encapsulate platform dependencies. These “platforms” might include: windowing system, operating system, database, etc. Too often, this encapsulatation is not engineered in advance, and lots of #ifdef case statements with options for all currently supported platforms begin to procreate like rabbits throughout the code. 

Discussion 

Provide a level of indirection that abstracts the creation of families of related or dependent objects without directly specifying their concrete classes. The “factory” object has the responsibility for providing creation services for the entire platform family. Clients never create platform objects directly, they ask the factory to do that for them.

This mechanism makes exchanging product families easy because the specific class of the factory object appears only once in the application - where it is instantiated. The application can wholesale replace the entire family of products simply by instantiating a different concrete instance of the abstract factory. Because the service provided by the factory object is so pervasive, it is routinely implemented as a Singleton. 

== Adapter Pattern ==
Convert the interface of a class into another interface clients expect. Adapter lets classes worktogether that couldn't otherwise because of incompatible interfaces.

Intent 
1)Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn’t otherwise because of incompatible interfaces. 
2)Wrap an existing class with a new interface. 
3)Impedance match an old component to a new system. 

Two types of adapter patterns 
1)Object Adapter pattern— relies on one object(the adapting object) containing another (theadapted object). 
2)Class Adapter pattern— implemented withmultiple inheritance

Problem 
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.

Discussion 
Reuse has always been painful and elusive. One reason has been the tribulation of designing something new, while reusing something old. There is always something not quite right between the old and the new. It may be physical dimensions or misalignment. It may be timing or synchronization. It may be unfortunate assumptions or competing standards.
 
It is like the problem of inserting a new three-prong electrical plug in an old two-prong wall outlet – some kind of adapter or intermediary is necessary.

Adapter is about creating an intermediary abstraction that translates, or maps, the old component to the new system. Clients call methods on the Adapter object which redirects them into calls to the legacy component. This strategy can be implemented either with inheritance or with aggregation.

Adapter functions as a wrapper or modifier of an existing class. It provides a different or translated view of that class.

==Mediator Pattern==

== Differences n similarities between Adapter and Facade ==
1)In both the Facade and Adapter pattern we havepreexisting classes.

2)In the Facade, however, we do not have aninterface we must design to, as we do in the Adapter pattern.

3)We are not interested in polymorphic behavior in theFacade, while in the Adapter, We probably am.(There are times when we just need to design to aparticular API and therefore must use an Adapter)

4)In the case of the Facade pattern, the motivation isto simplify the interface. With the Adapter, whilesimpler is better,We are trying to design to anexisting interface and cannot simplify things even if a simpler interface were otherwise possible.

Bottom line
: A Facade simplifies an interface whilean Adapter converts the interface into a preexistinginterface.

CSC/ECE 517 Fall 2012/ch2b 2w42 aa

2012-11-19T02:52:28Z

Aasawa: /* Facade Pattern */

=Introduction =

==Facade Pattern==

Intent 
1) 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. 
2) Wrap a complicated subsystem with a simpler interface. 

Non-Software examples 
In most of the Pizza centers, orders will be given through phone calls with the customer interacting with the Customer service representative. In this case, consumers do not have access to the Billing system, Kitchen and delivery department. The customer service representative acts as an interface and interacts with each of the departments involved in the transaction and ensures that Pizzas are delivered to the consumer.

We can relate this non-software example against the facade design pattern in the following way:

Customer Service representative corresponds to the facade.
Individual departments involved in the transaction correspond to Sub-systems.
Another example we can consider is Emergency services. In the event of fire we just inform an Emergency Service operator. The emergency operator interacts with police, ambulance and fire services and dispatches them. Here the client is shielded from individual emergency services.

Software examples 
Web Service Facade Solution Architecture provides an example for Facade design pattern. In this architectural solution, instead of rewriting legacy applications or customizing those with middleware to connect to other applications one by one, this solution helps create a "facade" for the legacy application. Other applications are easily "plugged into" this facade. By modeling a legacy application into its basic functions of create, read, update, and delete and then exposing these functions as Web methods, the Web service facade solution allows other applications to access legacy data by making use of common Web services through standardized protocols. In this way, Facade decouples layers so that they do not depend on each other which can make it easier to develop, to use and to promote code re-use.

The JIT (Just in-Time) compilers that we use everyday to process the Dotnet code is a prime example of the facade pattern. JIT compiler performs several lower level functions before converting MSIL into native code, such as verifying whether Microsoft intermediate language (MSIL) code can access the memory locations, checking MSIL code is correctly generated because incorrect MSIL can lead to a violation of the type safety rules, etc.

[[File:Facade-wo.JPG]] 
Without a Facade, Client contacts the Database 
to retrieve Company objects. It then retrieves 
Division objects from them and finally gains access 
to Employee objects.It uses four classes.

Problem 
A segment of the client community needs a simplified interface to the overall functionality of a complex subsystem. 

Facade discusses encapsulating a complex subsystem within a single interface object. This reduces the learning curve necessary to successfully leverage the subsystem. It also promotes decoupling the subsystem from its potentially many clients. On the other hand, if the Facade is the only access point for the subsystem, it will limit the features and flexibility that “power users” may need. The Facade object should be a fairly simple advocate or facilitator. It should not become an all-knowing oracle or “god” object. 

==Abstract Factory Pattern==

Intent 
1) Provide an interface for creating families of related or dependent objects without specifying their concrete classes. 
2) A hierarchy that encapsulates: many possible “platforms”, and the construction of a suite of “products”. 
3) The new operator considered harmful. 

Problem 

If an application is to be portable, it needs to encapsulate platform dependencies. These “platforms” might include: windowing system, operating system, database, etc. Too often, this encapsulatation is not engineered in advance, and lots of #ifdef case statements with options for all currently supported platforms begin to procreate like rabbits throughout the code. 

Discussion 

Provide a level of indirection that abstracts the creation of families of related or dependent objects without directly specifying their concrete classes. The “factory” object has the responsibility for providing creation services for the entire platform family. Clients never create platform objects directly, they ask the factory to do that for them.

This mechanism makes exchanging product families easy because the specific class of the factory object appears only once in the application - where it is instantiated. The application can wholesale replace the entire family of products simply by instantiating a different concrete instance of the abstract factory. Because the service provided by the factory object is so pervasive, it is routinely implemented as a Singleton. 

== Adapter Pattern ==
Convert the interface of a class into another interface clients expect. Adapter lets classes worktogether that couldn't otherwise because of incompatible interfaces.

Intent 
1)Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn’t otherwise because of incompatible interfaces. 
2)Wrap an existing class with a new interface. 
3)Impedance match an old component to a new system. 

Two types of adapter patterns 
1)Object Adapter pattern— relies on one object(the adapting object) containing another (theadapted object). 
2)Class Adapter pattern— implemented withmultiple inheritance

Problem 
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.

Discussion 
Reuse has always been painful and elusive. One reason has been the tribulation of designing something new, while reusing something old. There is always something not quite right between the old and the new. It may be physical dimensions or misalignment. It may be timing or synchronization. It may be unfortunate assumptions or competing standards.
 
It is like the problem of inserting a new three-prong electrical plug in an old two-prong wall outlet – some kind of adapter or intermediary is necessary.

Adapter is about creating an intermediary abstraction that translates, or maps, the old component to the new system. Clients call methods on the Adapter object which redirects them into calls to the legacy component. This strategy can be implemented either with inheritance or with aggregation.

Adapter functions as a wrapper or modifier of an existing class. It provides a different or translated view of that class.

==Mediator Pattern==

== Differences n similarities between Adapter and Facade ==
1)In both the Facade and Adapter pattern we havepreexisting classes.

2)In the Facade, however, we do not have aninterface we must design to, as we do in the Adapter pattern.

3)We are not interested in polymorphic behavior in theFacade, while in the Adapter, We probably am.(There are times when we just need to design to aparticular API and therefore must use an Adapter)

4)In the case of the Facade pattern, the motivation isto simplify the interface. With the Adapter, whilesimpler is better,We are trying to design to anexisting interface and cannot simplify things even if a simpler interface were otherwise possible.

Bottom line
: A Facade simplifies an interface whilean Adapter converts the interface into a preexistinginterface.

CSC/ECE 517 Fall 2012/ch2b 2w42 aa

2012-11-19T02:50:26Z

Aasawa: /* Facade Pattern */

=Introduction =

==Facade Pattern==

Intent 
1) 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. 
2) Wrap a complicated subsystem with a simpler interface. 

Non-Software examples 
In most of the Pizza centers, orders will be given through phone calls with the customer interacting with the Customer service representative. In this case, consumers do not have access to the Billing system, Kitchen and delivery department. The customer service representative acts as an interface and interacts with each of the departments involved in the transaction and ensures that Pizzas are delivered to the consumer.

We can relate this non-software example against the facade design pattern in the following way:

Customer Service representative corresponds to the facade.
Individual departments involved in the transaction correspond to Sub-systems.
Another example we can consider is Emergency services. In the event of fire we just inform an Emergency Service operator. The emergency operator interacts with police, ambulance and fire services and dispatches them. Here the client is shielded from individual emergency services.

Software examples 
Web Service Facade Solution Architecture provides an example for Facade design pattern. In this architectural solution, instead of rewriting legacy applications or customizing those with middleware to connect to other applications one by one, this solution helps create a "facade" for the legacy application. Other applications are easily "plugged into" this facade. By modeling a legacy application into its basic functions of create, read, update, and delete and then exposing these functions as Web methods, the Web service facade solution allows other applications to access legacy data by making use of common Web services through standardized protocols. In this way, Facade decouples layers so that they do not depend on each other which can make it easier to develop, to use and to promote code re-use.

The JIT (Just in-Time) compilers that we use everyday to process the Dotnet code is a prime example of the facade pattern. JIT compiler performs several lower level functions before converting MSIL into native code, such as verifying whether Microsoft intermediate language (MSIL) code can access the memory locations, checking MSIL code is correctly generated because incorrect MSIL can lead to a violation of the type safety rules, etc.

[[File:Facade-wo.JPG]] Without a Facade, Client contacts the Database to retrieve Company objects. It then retrieves Division objects from them and finally gains access to Employee objects.It uses four classes.

Problem 
A segment of the client community needs a simplified interface to the overall functionality of a complex subsystem. 

Facade discusses encapsulating a complex subsystem within a single interface object. This reduces the learning curve necessary to successfully leverage the subsystem. It also promotes decoupling the subsystem from its potentially many clients. On the other hand, if the Facade is the only access point for the subsystem, it will limit the features and flexibility that “power users” may need. The Facade object should be a fairly simple advocate or facilitator. It should not become an all-knowing oracle or “god” object. 

==Abstract Factory Pattern==

Intent 
1) Provide an interface for creating families of related or dependent objects without specifying their concrete classes. 
2) A hierarchy that encapsulates: many possible “platforms”, and the construction of a suite of “products”. 
3) The new operator considered harmful. 

Problem 

If an application is to be portable, it needs to encapsulate platform dependencies. These “platforms” might include: windowing system, operating system, database, etc. Too often, this encapsulatation is not engineered in advance, and lots of #ifdef case statements with options for all currently supported platforms begin to procreate like rabbits throughout the code. 

Discussion 

Provide a level of indirection that abstracts the creation of families of related or dependent objects without directly specifying their concrete classes. The “factory” object has the responsibility for providing creation services for the entire platform family. Clients never create platform objects directly, they ask the factory to do that for them.

This mechanism makes exchanging product families easy because the specific class of the factory object appears only once in the application - where it is instantiated. The application can wholesale replace the entire family of products simply by instantiating a different concrete instance of the abstract factory. Because the service provided by the factory object is so pervasive, it is routinely implemented as a Singleton. 

== Adapter Pattern ==
Convert the interface of a class into another interface clients expect. Adapter lets classes worktogether that couldn't otherwise because of incompatible interfaces.

Intent 
1)Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn’t otherwise because of incompatible interfaces. 
2)Wrap an existing class with a new interface. 
3)Impedance match an old component to a new system. 

Two types of adapter patterns 
1)Object Adapter pattern— relies on one object(the adapting object) containing another (theadapted object). 
2)Class Adapter pattern— implemented withmultiple inheritance

Problem 
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.

Discussion 
Reuse has always been painful and elusive. One reason has been the tribulation of designing something new, while reusing something old. There is always something not quite right between the old and the new. It may be physical dimensions or misalignment. It may be timing or synchronization. It may be unfortunate assumptions or competing standards.
 
It is like the problem of inserting a new three-prong electrical plug in an old two-prong wall outlet – some kind of adapter or intermediary is necessary.

Adapter is about creating an intermediary abstraction that translates, or maps, the old component to the new system. Clients call methods on the Adapter object which redirects them into calls to the legacy component. This strategy can be implemented either with inheritance or with aggregation.

Adapter functions as a wrapper or modifier of an existing class. It provides a different or translated view of that class.

==Mediator Pattern==

== Differences n similarities between Adapter and Facade ==
1)In both the Facade and Adapter pattern we havepreexisting classes.

2)In the Facade, however, we do not have aninterface we must design to, as we do in the Adapter pattern.

3)We are not interested in polymorphic behavior in theFacade, while in the Adapter, We probably am.(There are times when we just need to design to aparticular API and therefore must use an Adapter)

4)In the case of the Facade pattern, the motivation isto simplify the interface. With the Adapter, whilesimpler is better,We are trying to design to anexisting interface and cannot simplify things even if a simpler interface were otherwise possible.

Bottom line
: A Facade simplifies an interface whilean Adapter converts the interface into a preexistinginterface.

CSC/ECE 517 Fall 2012/ch2b 2w42 aa

2012-11-19T02:48:54Z

Aasawa: /* Facade Pattern */

=Introduction =

==Facade Pattern==

Intent 
1) 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. 
2) Wrap a complicated subsystem with a simpler interface. 

Non-Software examples 
In most of the Pizza centers, orders will be given through phone calls with the customer interacting with the Customer service representative. In this case, consumers do not have access to the Billing system, Kitchen and delivery department. The customer service representative acts as an interface and interacts with each of the departments involved in the transaction and ensures that Pizzas are delivered to the consumer.

We can relate this non-software example against the facade design pattern in the following way:

Customer Service representative corresponds to the facade.
Individual departments involved in the transaction correspond to Sub-systems.
Another example we can consider is Emergency services. In the event of fire we just inform an Emergency Service operator. The emergency operator interacts with police, ambulance and fire services and dispatches them. Here the client is shielded from individual emergency services.

Software examples 
Web Service Facade Solution Architecture provides an example for Facade design pattern. In this architectural solution, instead of rewriting legacy applications or customizing those with middleware to connect to other applications one by one, this solution helps create a "facade" for the legacy application. Other applications are easily "plugged into" this facade. By modeling a legacy application into its basic functions of create, read, update, and delete and then exposing these functions as Web methods, the Web service facade solution allows other applications to access legacy data by making use of common Web services through standardized protocols. In this way, Facade decouples layers so that they do not depend on each other which can make it easier to develop, to use and to promote code re-use.

The JIT (Just in-Time) compilers that we use everyday to process the Dotnet code is a prime example of the facade pattern. JIT compiler performs several lower level functions before converting MSIL into native code, such as verifying whether Microsoft intermediate language (MSIL) code can access the memory locations, checking MSIL code is correctly generated because incorrect MSIL can lead to a violation of the type safety rules, etc.

[[File:Facade-wo.JPG]] Without a Facade,
Client contacts the
Database to retrieve
Company objects. It
then retrieves
Division objects from
them and finally
gains access to
Employee objects.
It uses four classes.

Problem 
A segment of the client community needs a simplified interface to the overall functionality of a complex subsystem. 

Facade discusses encapsulating a complex subsystem within a single interface object. This reduces the learning curve necessary to successfully leverage the subsystem. It also promotes decoupling the subsystem from its potentially many clients. On the other hand, if the Facade is the only access point for the subsystem, it will limit the features and flexibility that “power users” may need. The Facade object should be a fairly simple advocate or facilitator. It should not become an all-knowing oracle or “god” object. 

==Abstract Factory Pattern==

Intent 
1) Provide an interface for creating families of related or dependent objects without specifying their concrete classes. 
2) A hierarchy that encapsulates: many possible “platforms”, and the construction of a suite of “products”. 
3) The new operator considered harmful. 

Problem 

If an application is to be portable, it needs to encapsulate platform dependencies. These “platforms” might include: windowing system, operating system, database, etc. Too often, this encapsulatation is not engineered in advance, and lots of #ifdef case statements with options for all currently supported platforms begin to procreate like rabbits throughout the code. 

Discussion 

Provide a level of indirection that abstracts the creation of families of related or dependent objects without directly specifying their concrete classes. The “factory” object has the responsibility for providing creation services for the entire platform family. Clients never create platform objects directly, they ask the factory to do that for them.

This mechanism makes exchanging product families easy because the specific class of the factory object appears only once in the application - where it is instantiated. The application can wholesale replace the entire family of products simply by instantiating a different concrete instance of the abstract factory. Because the service provided by the factory object is so pervasive, it is routinely implemented as a Singleton. 

== Adapter Pattern ==
Convert the interface of a class into another interface clients expect. Adapter lets classes worktogether that couldn't otherwise because of incompatible interfaces.

Intent 
1)Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn’t otherwise because of incompatible interfaces. 
2)Wrap an existing class with a new interface. 
3)Impedance match an old component to a new system. 

Two types of adapter patterns 
1)Object Adapter pattern— relies on one object(the adapting object) containing another (theadapted object). 
2)Class Adapter pattern— implemented withmultiple inheritance

Problem 
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.

Discussion 
Reuse has always been painful and elusive. One reason has been the tribulation of designing something new, while reusing something old. There is always something not quite right between the old and the new. It may be physical dimensions or misalignment. It may be timing or synchronization. It may be unfortunate assumptions or competing standards.
 
It is like the problem of inserting a new three-prong electrical plug in an old two-prong wall outlet – some kind of adapter or intermediary is necessary.

Adapter is about creating an intermediary abstraction that translates, or maps, the old component to the new system. Clients call methods on the Adapter object which redirects them into calls to the legacy component. This strategy can be implemented either with inheritance or with aggregation.

Adapter functions as a wrapper or modifier of an existing class. It provides a different or translated view of that class.

==Mediator Pattern==

== Differences n similarities between Adapter and Facade ==
1)In both the Facade and Adapter pattern we havepreexisting classes.

2)In the Facade, however, we do not have aninterface we must design to, as we do in the Adapter pattern.

3)We are not interested in polymorphic behavior in theFacade, while in the Adapter, We probably am.(There are times when we just need to design to aparticular API and therefore must use an Adapter)

4)In the case of the Facade pattern, the motivation isto simplify the interface. With the Adapter, whilesimpler is better,We are trying to design to anexisting interface and cannot simplify things even if a simpler interface were otherwise possible.

Bottom line
: A Facade simplifies an interface whilean Adapter converts the interface into a preexistinginterface.

CSC/ECE 517 Fall 2012/ch2b 2w42 aa

2012-11-19T02:47:59Z

Aasawa: /* Facade Pattern */

=Introduction =

==Facade Pattern==

Intent 
1) 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. 
2) Wrap a complicated subsystem with a simpler interface. 

Non-Software examples 
In most of the Pizza centers, orders will be given through phone calls with the customer interacting with the Customer service representative. In this case, consumers do not have access to the Billing system, Kitchen and delivery department. The customer service representative acts as an interface and interacts with each of the departments involved in the transaction and ensures that Pizzas are delivered to the consumer.

We can relate this non-software example against the facade design pattern in the following way:

Customer Service representative corresponds to the facade.
Individual departments involved in the transaction correspond to Sub-systems.
Another example we can consider is Emergency services. In the event of fire we just inform an Emergency Service operator. The emergency operator interacts with police, ambulance and fire services and dispatches them. Here the client is shielded from individual emergency services.

Software examples 
Web Service Facade Solution Architecture provides an example for Facade design pattern. In this architectural solution, instead of rewriting legacy applications or customizing those with middleware to connect to other applications one by one, this solution helps create a "facade" for the legacy application. Other applications are easily "plugged into" this facade. By modeling a legacy application into its basic functions of create, read, update, and delete and then exposing these functions as Web methods, the Web service facade solution allows other applications to access legacy data by making use of common Web services through standardized protocols. In this way, Facade decouples layers so that they do not depend on each other which can make it easier to develop, to use and to promote code re-use.

The JIT (Just in-Time) compilers that we use everyday to process the Dotnet code is a prime example of the facade pattern. JIT compiler performs several lower level functions before converting MSIL into native code, such as verifying whether Microsoft intermediate language (MSIL) code can access the memory locations, checking MSIL code is correctly generated because incorrect MSIL can lead to a violation of the type safety rules, etc.

[[File:Facade-wo.JPG]]

Problem 
A segment of the client community needs a simplified interface to the overall functionality of a complex subsystem. 

Facade discusses encapsulating a complex subsystem within a single interface object. This reduces the learning curve necessary to successfully leverage the subsystem. It also promotes decoupling the subsystem from its potentially many clients. On the other hand, if the Facade is the only access point for the subsystem, it will limit the features and flexibility that “power users” may need. The Facade object should be a fairly simple advocate or facilitator. It should not become an all-knowing oracle or “god” object. 

==Abstract Factory Pattern==

Intent 
1) Provide an interface for creating families of related or dependent objects without specifying their concrete classes. 
2) A hierarchy that encapsulates: many possible “platforms”, and the construction of a suite of “products”. 
3) The new operator considered harmful. 

Problem 

If an application is to be portable, it needs to encapsulate platform dependencies. These “platforms” might include: windowing system, operating system, database, etc. Too often, this encapsulatation is not engineered in advance, and lots of #ifdef case statements with options for all currently supported platforms begin to procreate like rabbits throughout the code. 

Discussion 

Provide a level of indirection that abstracts the creation of families of related or dependent objects without directly specifying their concrete classes. The “factory” object has the responsibility for providing creation services for the entire platform family. Clients never create platform objects directly, they ask the factory to do that for them.

This mechanism makes exchanging product families easy because the specific class of the factory object appears only once in the application - where it is instantiated. The application can wholesale replace the entire family of products simply by instantiating a different concrete instance of the abstract factory. Because the service provided by the factory object is so pervasive, it is routinely implemented as a Singleton. 

== Adapter Pattern ==
Convert the interface of a class into another interface clients expect. Adapter lets classes worktogether that couldn't otherwise because of incompatible interfaces.

Intent 
1)Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn’t otherwise because of incompatible interfaces. 
2)Wrap an existing class with a new interface. 
3)Impedance match an old component to a new system. 

Two types of adapter patterns 
1)Object Adapter pattern— relies on one object(the adapting object) containing another (theadapted object). 
2)Class Adapter pattern— implemented withmultiple inheritance

Problem 
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.

Discussion 
Reuse has always been painful and elusive. One reason has been the tribulation of designing something new, while reusing something old. There is always something not quite right between the old and the new. It may be physical dimensions or misalignment. It may be timing or synchronization. It may be unfortunate assumptions or competing standards.
 
It is like the problem of inserting a new three-prong electrical plug in an old two-prong wall outlet – some kind of adapter or intermediary is necessary.

Adapter is about creating an intermediary abstraction that translates, or maps, the old component to the new system. Clients call methods on the Adapter object which redirects them into calls to the legacy component. This strategy can be implemented either with inheritance or with aggregation.

Adapter functions as a wrapper or modifier of an existing class. It provides a different or translated view of that class.

==Mediator Pattern==

== Differences n similarities between Adapter and Facade ==
1)In both the Facade and Adapter pattern we havepreexisting classes.

2)In the Facade, however, we do not have aninterface we must design to, as we do in the Adapter pattern.

3)We are not interested in polymorphic behavior in theFacade, while in the Adapter, We probably am.(There are times when we just need to design to aparticular API and therefore must use an Adapter)

4)In the case of the Facade pattern, the motivation isto simplify the interface. With the Adapter, whilesimpler is better,We are trying to design to anexisting interface and cannot simplify things even if a simpler interface were otherwise possible.

Bottom line
: A Facade simplifies an interface whilean Adapter converts the interface into a preexistinginterface.

CSC/ECE 517 Fall 2012/ch2b 2w42 aa

2012-11-19T02:47:14Z

Aasawa: /* Facade Pattern */

=Introduction =

==Facade Pattern==

Intent 
1) 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. 
2) Wrap a complicated subsystem with a simpler interface. 

Non-Software examples 
In most of the Pizza centers, orders will be given through phone calls with the customer interacting with the Customer service representative. In this case, consumers do not have access to the Billing system, Kitchen and delivery department. The customer service representative acts as an interface and interacts with each of the departments involved in the transaction and ensures that Pizzas are delivered to the consumer.

We can relate this non-software example against the facade design pattern in the following way:

Customer Service representative corresponds to the facade.
Individual departments involved in the transaction correspond to Sub-systems.
Another example we can consider is Emergency services. In the event of fire we just inform an Emergency Service operator. The emergency operator interacts with police, ambulance and fire services and dispatches them. Here the client is shielded from individual emergency services.

Software examples 
Web Service Facade Solution Architecture provides an example for Facade design pattern. In this architectural solution, instead of rewriting legacy applications or customizing those with middleware to connect to other applications one by one, this solution helps create a "facade" for the legacy application. Other applications are easily "plugged into" this facade. By modeling a legacy application into its basic functions of create, read, update, and delete and then exposing these functions as Web methods, the Web service facade solution allows other applications to access legacy data by making use of common Web services through standardized protocols. In this way, Facade decouples layers so that they do not depend on each other which can make it easier to develop, to use and to promote code re-use.

The JIT (Just in-Time) compilers that we use everyday to process the Dotnet code is a prime example of the facade pattern. JIT compiler performs several lower level functions before converting MSIL into native code, such as verifying whether Microsoft intermediate language (MSIL) code can access the memory locations, checking MSIL code is correctly generated because incorrect MSIL can lead to a violation of the type safety rules, etc.

[[File:Facade-wo.jpg]]

Problem 
A segment of the client community needs a simplified interface to the overall functionality of a complex subsystem. 

Facade discusses encapsulating a complex subsystem within a single interface object. This reduces the learning curve necessary to successfully leverage the subsystem. It also promotes decoupling the subsystem from its potentially many clients. On the other hand, if the Facade is the only access point for the subsystem, it will limit the features and flexibility that “power users” may need. The Facade object should be a fairly simple advocate or facilitator. It should not become an all-knowing oracle or “god” object. 

==Abstract Factory Pattern==

Intent 
1) Provide an interface for creating families of related or dependent objects without specifying their concrete classes. 
2) A hierarchy that encapsulates: many possible “platforms”, and the construction of a suite of “products”. 
3) The new operator considered harmful. 

Problem 

If an application is to be portable, it needs to encapsulate platform dependencies. These “platforms” might include: windowing system, operating system, database, etc. Too often, this encapsulatation is not engineered in advance, and lots of #ifdef case statements with options for all currently supported platforms begin to procreate like rabbits throughout the code. 

Discussion 

Provide a level of indirection that abstracts the creation of families of related or dependent objects without directly specifying their concrete classes. The “factory” object has the responsibility for providing creation services for the entire platform family. Clients never create platform objects directly, they ask the factory to do that for them.

This mechanism makes exchanging product families easy because the specific class of the factory object appears only once in the application - where it is instantiated. The application can wholesale replace the entire family of products simply by instantiating a different concrete instance of the abstract factory. Because the service provided by the factory object is so pervasive, it is routinely implemented as a Singleton. 

== Adapter Pattern ==
Convert the interface of a class into another interface clients expect. Adapter lets classes worktogether that couldn't otherwise because of incompatible interfaces.

Intent 
1)Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn’t otherwise because of incompatible interfaces. 
2)Wrap an existing class with a new interface. 
3)Impedance match an old component to a new system. 

Two types of adapter patterns 
1)Object Adapter pattern— relies on one object(the adapting object) containing another (theadapted object). 
2)Class Adapter pattern— implemented withmultiple inheritance

Problem 
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.

Discussion 
Reuse has always been painful and elusive. One reason has been the tribulation of designing something new, while reusing something old. There is always something not quite right between the old and the new. It may be physical dimensions or misalignment. It may be timing or synchronization. It may be unfortunate assumptions or competing standards.
 
It is like the problem of inserting a new three-prong electrical plug in an old two-prong wall outlet – some kind of adapter or intermediary is necessary.

Adapter is about creating an intermediary abstraction that translates, or maps, the old component to the new system. Clients call methods on the Adapter object which redirects them into calls to the legacy component. This strategy can be implemented either with inheritance or with aggregation.

Adapter functions as a wrapper or modifier of an existing class. It provides a different or translated view of that class.

==Mediator Pattern==

== Differences n similarities between Adapter and Facade ==
1)In both the Facade and Adapter pattern we havepreexisting classes.

2)In the Facade, however, we do not have aninterface we must design to, as we do in the Adapter pattern.

3)We are not interested in polymorphic behavior in theFacade, while in the Adapter, We probably am.(There are times when we just need to design to aparticular API and therefore must use an Adapter)

4)In the case of the Facade pattern, the motivation isto simplify the interface. With the Adapter, whilesimpler is better,We are trying to design to anexisting interface and cannot simplify things even if a simpler interface were otherwise possible.

Bottom line
: A Facade simplifies an interface whilean Adapter converts the interface into a preexistinginterface.

CSC/ECE 517 Fall 2012/ch2b 2w42 aa

2012-11-19T02:44:11Z

Aasawa: /* Facade Pattern */

=Introduction =

==Facade Pattern==

Intent 
1) 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. 
2) Wrap a complicated subsystem with a simpler interface. 

Non-Software examples 
In most of the Pizza centers, orders will be given through phone calls with the customer interacting with the Customer service representative. In this case, consumers do not have access to the Billing system, Kitchen and delivery department. The customer service representative acts as an interface and interacts with each of the departments involved in the transaction and ensures that Pizzas are delivered to the consumer.

We can relate this non-software example against the facade design pattern in the following way:

Customer Service representative corresponds to the facade.
Individual departments involved in the transaction correspond to Sub-systems.
Another example we can consider is Emergency services. In the event of fire we just inform an Emergency Service operator. The emergency operator interacts with police, ambulance and fire services and dispatches them. Here the client is shielded from individual emergency services.

Software examples 
Web Service Facade Solution Architecture provides an example for Facade design pattern. In this architectural solution, instead of rewriting legacy applications or customizing those with middleware to connect to other applications one by one, this solution helps create a "facade" for the legacy application. Other applications are easily "plugged into" this facade. By modeling a legacy application into its basic functions of create, read, update, and delete and then exposing these functions as Web methods, the Web service facade solution allows other applications to access legacy data by making use of common Web services through standardized protocols. In this way, Facade decouples layers so that they do not depend on each other which can make it easier to develop, to use and to promote code re-use.

The JIT (Just in-Time) compilers that we use everyday to process the Dotnet code is a prime example of the facade pattern. JIT compiler performs several lower level functions before converting MSIL into native code, such as verifying whether Microsoft intermediate language (MSIL) code can access the memory locations, checking MSIL code is correctly generated because incorrect MSIL can lead to a violation of the type safety rules, etc.

[[File:Facade-wo.jpg]]
Problem 
A segment of the client community needs a simplified interface to the overall functionality of a complex subsystem. 

Facade discusses encapsulating a complex subsystem within a single interface object. This reduces the learning curve necessary to successfully leverage the subsystem. It also promotes decoupling the subsystem from its potentially many clients. On the other hand, if the Facade is the only access point for the subsystem, it will limit the features and flexibility that “power users” may need. The Facade object should be a fairly simple advocate or facilitator. It should not become an all-knowing oracle or “god” object. 

==Abstract Factory Pattern==

Intent 
1) Provide an interface for creating families of related or dependent objects without specifying their concrete classes. 
2) A hierarchy that encapsulates: many possible “platforms”, and the construction of a suite of “products”. 
3) The new operator considered harmful. 

Problem 

If an application is to be portable, it needs to encapsulate platform dependencies. These “platforms” might include: windowing system, operating system, database, etc. Too often, this encapsulatation is not engineered in advance, and lots of #ifdef case statements with options for all currently supported platforms begin to procreate like rabbits throughout the code. 

Discussion 

Provide a level of indirection that abstracts the creation of families of related or dependent objects without directly specifying their concrete classes. The “factory” object has the responsibility for providing creation services for the entire platform family. Clients never create platform objects directly, they ask the factory to do that for them.

This mechanism makes exchanging product families easy because the specific class of the factory object appears only once in the application - where it is instantiated. The application can wholesale replace the entire family of products simply by instantiating a different concrete instance of the abstract factory. Because the service provided by the factory object is so pervasive, it is routinely implemented as a Singleton. 

== Adapter Pattern ==
Convert the interface of a class into another interface clients expect. Adapter lets classes worktogether that couldn't otherwise because of incompatible interfaces.

Intent 
1)Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn’t otherwise because of incompatible interfaces. 
2)Wrap an existing class with a new interface. 
3)Impedance match an old component to a new system. 

Two types of adapter patterns 
1)Object Adapter pattern— relies on one object(the adapting object) containing another (theadapted object). 
2)Class Adapter pattern— implemented withmultiple inheritance

Problem 
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.

Discussion 
Reuse has always been painful and elusive. One reason has been the tribulation of designing something new, while reusing something old. There is always something not quite right between the old and the new. It may be physical dimensions or misalignment. It may be timing or synchronization. It may be unfortunate assumptions or competing standards.
 
It is like the problem of inserting a new three-prong electrical plug in an old two-prong wall outlet – some kind of adapter or intermediary is necessary.

Adapter is about creating an intermediary abstraction that translates, or maps, the old component to the new system. Clients call methods on the Adapter object which redirects them into calls to the legacy component. This strategy can be implemented either with inheritance or with aggregation.

Adapter functions as a wrapper or modifier of an existing class. It provides a different or translated view of that class.

==Mediator Pattern==

== Differences n similarities between Adapter and Facade ==
1)In both the Facade and Adapter pattern we havepreexisting classes.

2)In the Facade, however, we do not have aninterface we must design to, as we do in the Adapter pattern.

3)We are not interested in polymorphic behavior in theFacade, while in the Adapter, We probably am.(There are times when we just need to design to aparticular API and therefore must use an Adapter)

4)In the case of the Facade pattern, the motivation isto simplify the interface. With the Adapter, whilesimpler is better,We are trying to design to anexisting interface and cannot simplify things even if a simpler interface were otherwise possible.

Bottom line
: A Facade simplifies an interface whilean Adapter converts the interface into a preexistinginterface.