Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2012/ch2b 2w42 aa

2012-11-20T13:19:56Z

Akoradh: /* Adapter Pattern Example */

=Introduction =

== Facade Pattern <ref>Facade Pattern [http://sourcemaking.com/design_patterns/facade]</ref>==

Facade Pattern provides a unified interface to a set of interfaces in a subsystem. It wraps 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 <ref>Adapter Pattern - [http://sourcemaking.com/design_patterns/adapter]</ref> ==

Adapter Pattern converts the interface of a class into another interface clients expect. Adapter lets classes work together that couldn’t otherwise because of incompatible interfaces. It wraps an existing class with a new interface. It aims to match an old component to a new system. It strives to convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn't otherwise because of incompatible interfaces.

== Abstract Factory Pattern <ref>Abstract Factory Pattern [http://sourcemaking.com/design_patterns/abstract_factory]</ref> ==

Abstract Factory Pattern provides an interface for creating families of related or dependent objects without specifying their concrete classes. It defines a hierarchy that encapsulates: many possible “platforms”, and the construction of a suite of “products”. 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 <ref>Mediator Pattern [http://sourcemaking.com/design_patterns/mediator]</ref> ==

Mediator Pattern defines 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. It aims to design an intermediary to decouple many peers. It promotes 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 class is a wrapper which modifies an existing class. It provides an alternate view of that class. In cases where a third party component is readily available and provides functionality that needs to be used, but the interfaces exposed by the component does not have an exact match with the system that is being developed, adapter classes can be used. The mismatch can be diverse such as the way arguments are handled, some assumptions about the underlying implementations, physical dimensions, misalignment, timing or synchronization etc. 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 Pattern creates an intermediate class that maps the one component to other. The calls to methods on the Adapter object is redirected by the adapter into calls to the legacy component. This strategy can be implemented either with inheritance or with aggregation. 

== Adapter Pattern Example <ref>Adapter Pattern Example [http://sourcemaking.com/design_patterns/adapter/java/1]</ref> ==
<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, in the Facade example, assume that the user of OrderFacade needs to obtain order id in a different representation. To handle such scenario, a new adapter class OrderFacadeAdapter is defined. It implements all the methods of the OrderFacade and in each method where order id is referenced, it makes necessary changes to convert order id from one form to other and invoke other methods of the subsystem.

== Example ==
<pre>
public Class OrderFacadeAdapter {
public OrderId placeOrder(...) {
//convert order id from int to type 'OrderId' and return
}
}
</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 ==
<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 <ref>Facade Vs Mediator [http://stackoverflow.com/questions/481984/facade-vs-mediator]</ref> =
Mediator Pattern is used to avoid the direct dependencies between reusable pieces of software i.e if one of the components changes, then all components which are directly connected to it changes. One of the important example is the resources permission in unix. There are three categories of permissions - owner, group and others. Some users with similar characteristics are formed into a group. 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. 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]]

== Facade Example ==
<pre>
class Logger {
public void initLogger( String loggerName ) {
//generate a file logger. Create file if not found. Initialize
}
public void log( String message ) {
//call the file logger's log method
}
}
</pre>

The log functionality is provided by the file logger. The class Logger hides the handling of files, deletion of files etc. The init method creates a file if not present, defines the size of the file before roll over, initializes some state of Logger. Logger internally calls file logger's log method. It does not define a new functionality. It delegates to existing objects.

== Mediator Example ==
<pre>
public void initLogger( String loggerName ) {
//based on some global parameters, set logger as either file or socket or both
}

public void log( String message ) {
//depending on the initialization in initLogger, log the message to a file or socket or both.
//handle file input-ouput and socket input-ouput/
}
</pre>

In above example, depending on the initialization, the log methods handles the logging of message to either a file or socket or both. It has to have functionality to handle input and output to both file and socket.

== Differences and Similarities ==
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). Facade is an structural pattern, that is it describes the composition of the objects, while the mediator is an behavioral, that is , it describes the way the objects interact.

=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
* http://stackoverflow.com/questions/481984/facade-vs-mediator

CSC/ECE 517 Fall 2012/ch2b 2w42 aa

2012-11-20T13:17:34Z

Akoradh: /* Mediator Pattern and Facade Pattern [http://stackoverflow.com/questions/481984/facade-vs-mediator] */

=Introduction =

== Facade Pattern <ref>Facade Pattern [http://sourcemaking.com/design_patterns/facade]</ref>==

Facade Pattern provides a unified interface to a set of interfaces in a subsystem. It wraps 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 <ref>Adapter Pattern - [http://sourcemaking.com/design_patterns/adapter]</ref> ==

Adapter Pattern converts the interface of a class into another interface clients expect. Adapter lets classes work together that couldn’t otherwise because of incompatible interfaces. It wraps an existing class with a new interface. It aims to match an old component to a new system. It strives to convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn't otherwise because of incompatible interfaces.

== Abstract Factory Pattern <ref>Abstract Factory Pattern [http://sourcemaking.com/design_patterns/abstract_factory]</ref> ==

Abstract Factory Pattern provides an interface for creating families of related or dependent objects without specifying their concrete classes. It defines a hierarchy that encapsulates: many possible “platforms”, and the construction of a suite of “products”. 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 <ref>Mediator Pattern [http://sourcemaking.com/design_patterns/mediator]</ref> ==

Mediator Pattern defines 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. It aims to design an intermediary to decouple many peers. It promotes 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 class is a wrapper which modifies an existing class. It provides an alternate view of that class. In cases where a third party component is readily available and provides functionality that needs to be used, but the interfaces exposed by the component does not have an exact match with the system that is being developed, adapter classes can be used. The mismatch can be diverse such as the way arguments are handled, some assumptions about the underlying implementations, physical dimensions, misalignment, timing or synchronization etc. 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 Pattern creates an intermediate class that maps the one component to other. The calls to methods on the Adapter object is redirected by the adapter 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, in the Facade example, assume that the user of OrderFacade needs to obtain order id in a different representation. To handle such scenario, a new adapter class OrderFacadeAdapter is defined. It implements all the methods of the OrderFacade and in each method where order id is referenced, it makes necessary changes to convert order id from one form to other and invoke other methods of the subsystem.

== Example ==
<pre>
public Class OrderFacadeAdapter {
public OrderId placeOrder(...) {
//convert order id from int to type 'OrderId' and return
}
}
</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 ==
<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 <ref>Facade Vs Mediator [http://stackoverflow.com/questions/481984/facade-vs-mediator]</ref> =
Mediator Pattern is used to avoid the direct dependencies between reusable pieces of software i.e if one of the components changes, then all components which are directly connected to it changes. One of the important example is the resources permission in unix. There are three categories of permissions - owner, group and others. Some users with similar characteristics are formed into a group. 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. 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]]

== Facade Example ==
<pre>
class Logger {
public void initLogger( String loggerName ) {
//generate a file logger. Create file if not found. Initialize
}
public void log( String message ) {
//call the file logger's log method
}
}
</pre>

The log functionality is provided by the file logger. The class Logger hides the handling of files, deletion of files etc. The init method creates a file if not present, defines the size of the file before roll over, initializes some state of Logger. Logger internally calls file logger's log method. It does not define a new functionality. It delegates to existing objects.

== Mediator Example ==
<pre>
public void initLogger( String loggerName ) {
//based on some global parameters, set logger as either file or socket or both
}

public void log( String message ) {
//depending on the initialization in initLogger, log the message to a file or socket or both.
//handle file input-ouput and socket input-ouput/
}
</pre>

In above example, depending on the initialization, the log methods handles the logging of message to either a file or socket or both. It has to have functionality to handle input and output to both file and socket.

== Differences and Similarities ==
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). Facade is an structural pattern, that is it describes the composition of the objects, while the mediator is an behavioral, that is , it describes the way the objects interact.

=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
* http://stackoverflow.com/questions/481984/facade-vs-mediator

CSC/ECE 517 Fall 2012/ch2b 2w42 aa

2012-11-20T13:16:58Z

Akoradh: /* Introduction */

=Introduction =

== Facade Pattern <ref>Facade Pattern [http://sourcemaking.com/design_patterns/facade]</ref>==

Facade Pattern provides a unified interface to a set of interfaces in a subsystem. It wraps 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 <ref>Adapter Pattern - [http://sourcemaking.com/design_patterns/adapter]</ref> ==

Adapter Pattern converts the interface of a class into another interface clients expect. Adapter lets classes work together that couldn’t otherwise because of incompatible interfaces. It wraps an existing class with a new interface. It aims to match an old component to a new system. It strives to convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn't otherwise because of incompatible interfaces.

== Abstract Factory Pattern <ref>Abstract Factory Pattern [http://sourcemaking.com/design_patterns/abstract_factory]</ref> ==

Abstract Factory Pattern provides an interface for creating families of related or dependent objects without specifying their concrete classes. It defines a hierarchy that encapsulates: many possible “platforms”, and the construction of a suite of “products”. 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 <ref>Mediator Pattern [http://sourcemaking.com/design_patterns/mediator]</ref> ==

Mediator Pattern defines 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. It aims to design an intermediary to decouple many peers. It promotes 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 class is a wrapper which modifies an existing class. It provides an alternate view of that class. In cases where a third party component is readily available and provides functionality that needs to be used, but the interfaces exposed by the component does not have an exact match with the system that is being developed, adapter classes can be used. The mismatch can be diverse such as the way arguments are handled, some assumptions about the underlying implementations, physical dimensions, misalignment, timing or synchronization etc. 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 Pattern creates an intermediate class that maps the one component to other. The calls to methods on the Adapter object is redirected by the adapter 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, in the Facade example, assume that the user of OrderFacade needs to obtain order id in a different representation. To handle such scenario, a new adapter class OrderFacadeAdapter is defined. It implements all the methods of the OrderFacade and in each method where order id is referenced, it makes necessary changes to convert order id from one form to other and invoke other methods of the subsystem.

== Example ==
<pre>
public Class OrderFacadeAdapter {
public OrderId placeOrder(...) {
//convert order id from int to type 'OrderId' and return
}
}
</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 ==
<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 <ref>[http://stackoverflow.com/questions/481984/facade-vs-mediator]</ref> =
Mediator Pattern is used to avoid the direct dependencies between reusable pieces of software i.e if one of the components changes, then all components which are directly connected to it changes. One of the important example is the resources permission in unix. There are three categories of permissions - owner, group and others. Some users with similar characteristics are formed into a group. 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. 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]]

== Facade Example ==
<pre>
class Logger {
public void initLogger( String loggerName ) {
//generate a file logger. Create file if not found. Initialize
}
public void log( String message ) {
//call the file logger's log method
}
}
</pre>

The log functionality is provided by the file logger. The class Logger hides the handling of files, deletion of files etc. The init method creates a file if not present, defines the size of the file before roll over, initializes some state of Logger. Logger internally calls file logger's log method. It does not define a new functionality. It delegates to existing objects.

== Mediator Example ==
<pre>
public void initLogger( String loggerName ) {
//based on some global parameters, set logger as either file or socket or both
}

public void log( String message ) {
//depending on the initialization in initLogger, log the message to a file or socket or both.
//handle file input-ouput and socket input-ouput/
}
</pre>

In above example, depending on the initialization, the log methods handles the logging of message to either a file or socket or both. It has to have functionality to handle input and output to both file and socket.

== Differences and Similarities ==
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). Facade is an structural pattern, that is it describes the composition of the objects, while the mediator is an behavioral, that is , it describes the way the objects interact.

=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
* http://stackoverflow.com/questions/481984/facade-vs-mediator

CSC/ECE 517 Fall 2012/ch2b 2w42 aa

2012-11-20T13:16:00Z

Akoradh: /* Introduction */

=Introduction =

== Facade Pattern <ref>[http://sourcemaking.com/design_patterns/facade]</ref>==

Facade Pattern provides a unified interface to a set of interfaces in a subsystem. It wraps 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 <ref>Adapter Pattern - [http://sourcemaking.com/design_patterns/adapter]</ref> ==

Adapter Pattern converts the interface of a class into another interface clients expect. Adapter lets classes work together that couldn’t otherwise because of incompatible interfaces. It wraps an existing class with a new interface. It aims to match an old component to a new system. It strives to convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn't otherwise because of incompatible interfaces.

== Abstract Factory Pattern <ref>[http://sourcemaking.com/design_patterns/abstract_factory]</ref> ==

Abstract Factory Pattern provides an interface for creating families of related or dependent objects without specifying their concrete classes. It defines a hierarchy that encapsulates: many possible “platforms”, and the construction of a suite of “products”. 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 <ref>[http://sourcemaking.com/design_patterns/mediator]</ref> ==

Mediator Pattern defines 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. It aims to design an intermediary to decouple many peers. It promotes 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 class is a wrapper which modifies an existing class. It provides an alternate view of that class. In cases where a third party component is readily available and provides functionality that needs to be used, but the interfaces exposed by the component does not have an exact match with the system that is being developed, adapter classes can be used. The mismatch can be diverse such as the way arguments are handled, some assumptions about the underlying implementations, physical dimensions, misalignment, timing or synchronization etc. 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 Pattern creates an intermediate class that maps the one component to other. The calls to methods on the Adapter object is redirected by the adapter 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, in the Facade example, assume that the user of OrderFacade needs to obtain order id in a different representation. To handle such scenario, a new adapter class OrderFacadeAdapter is defined. It implements all the methods of the OrderFacade and in each method where order id is referenced, it makes necessary changes to convert order id from one form to other and invoke other methods of the subsystem.

== Example ==
<pre>
public Class OrderFacadeAdapter {
public OrderId placeOrder(...) {
//convert order id from int to type 'OrderId' and return
}
}
</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 ==
<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 <ref>[http://stackoverflow.com/questions/481984/facade-vs-mediator]</ref> =
Mediator Pattern is used to avoid the direct dependencies between reusable pieces of software i.e if one of the components changes, then all components which are directly connected to it changes. One of the important example is the resources permission in unix. There are three categories of permissions - owner, group and others. Some users with similar characteristics are formed into a group. 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. 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]]

== Facade Example ==
<pre>
class Logger {
public void initLogger( String loggerName ) {
//generate a file logger. Create file if not found. Initialize
}
public void log( String message ) {
//call the file logger's log method
}
}
</pre>

The log functionality is provided by the file logger. The class Logger hides the handling of files, deletion of files etc. The init method creates a file if not present, defines the size of the file before roll over, initializes some state of Logger. Logger internally calls file logger's log method. It does not define a new functionality. It delegates to existing objects.

== Mediator Example ==
<pre>
public void initLogger( String loggerName ) {
//based on some global parameters, set logger as either file or socket or both
}

public void log( String message ) {
//depending on the initialization in initLogger, log the message to a file or socket or both.
//handle file input-ouput and socket input-ouput/
}
</pre>

In above example, depending on the initialization, the log methods handles the logging of message to either a file or socket or both. It has to have functionality to handle input and output to both file and socket.

== Differences and Similarities ==
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). Facade is an structural pattern, that is it describes the composition of the objects, while the mediator is an behavioral, that is , it describes the way the objects interact.

=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
* http://stackoverflow.com/questions/481984/facade-vs-mediator

CSC/ECE 517 Fall 2012/ch2b 2w42 aa

2012-11-20T13:15:23Z

Akoradh: /* Introduction */

=Introduction =

== Facade Pattern <ref>[http://sourcemaking.com/design_patterns/facade]</ref>==

Facade Pattern provides a unified interface to a set of interfaces in a subsystem. It wraps 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 <ref>[Adapter Pattern - http://sourcemaking.com/design_patterns/adapter]</ref> ==

Adapter Pattern converts the interface of a class into another interface clients expect. Adapter lets classes work together that couldn’t otherwise because of incompatible interfaces. It wraps an existing class with a new interface. It aims to match an old component to a new system. It strives to convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn't otherwise because of incompatible interfaces.

== Abstract Factory Pattern <ref>[http://sourcemaking.com/design_patterns/abstract_factory]</ref> ==

Abstract Factory Pattern provides an interface for creating families of related or dependent objects without specifying their concrete classes. It defines a hierarchy that encapsulates: many possible “platforms”, and the construction of a suite of “products”. 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 <ref>[http://sourcemaking.com/design_patterns/mediator]</ref> ==

Mediator Pattern defines 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. It aims to design an intermediary to decouple many peers. It promotes 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 class is a wrapper which modifies an existing class. It provides an alternate view of that class. In cases where a third party component is readily available and provides functionality that needs to be used, but the interfaces exposed by the component does not have an exact match with the system that is being developed, adapter classes can be used. The mismatch can be diverse such as the way arguments are handled, some assumptions about the underlying implementations, physical dimensions, misalignment, timing or synchronization etc. 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 Pattern creates an intermediate class that maps the one component to other. The calls to methods on the Adapter object is redirected by the adapter 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, in the Facade example, assume that the user of OrderFacade needs to obtain order id in a different representation. To handle such scenario, a new adapter class OrderFacadeAdapter is defined. It implements all the methods of the OrderFacade and in each method where order id is referenced, it makes necessary changes to convert order id from one form to other and invoke other methods of the subsystem.

== Example ==
<pre>
public Class OrderFacadeAdapter {
public OrderId placeOrder(...) {
//convert order id from int to type 'OrderId' and return
}
}
</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 ==
<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 <ref>[http://stackoverflow.com/questions/481984/facade-vs-mediator]</ref> =
Mediator Pattern is used to avoid the direct dependencies between reusable pieces of software i.e if one of the components changes, then all components which are directly connected to it changes. One of the important example is the resources permission in unix. There are three categories of permissions - owner, group and others. Some users with similar characteristics are formed into a group. 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. 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]]

== Facade Example ==
<pre>
class Logger {
public void initLogger( String loggerName ) {
//generate a file logger. Create file if not found. Initialize
}
public void log( String message ) {
//call the file logger's log method
}
}
</pre>

The log functionality is provided by the file logger. The class Logger hides the handling of files, deletion of files etc. The init method creates a file if not present, defines the size of the file before roll over, initializes some state of Logger. Logger internally calls file logger's log method. It does not define a new functionality. It delegates to existing objects.

== Mediator Example ==
<pre>
public void initLogger( String loggerName ) {
//based on some global parameters, set logger as either file or socket or both
}

public void log( String message ) {
//depending on the initialization in initLogger, log the message to a file or socket or both.
//handle file input-ouput and socket input-ouput/
}
</pre>

In above example, depending on the initialization, the log methods handles the logging of message to either a file or socket or both. It has to have functionality to handle input and output to both file and socket.

== Differences and Similarities ==
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). Facade is an structural pattern, that is it describes the composition of the objects, while the mediator is an behavioral, that is , it describes the way the objects interact.

=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
* http://stackoverflow.com/questions/481984/facade-vs-mediator

CSC/ECE 517 Fall 2012/ch2b 2w42 aa

2012-11-20T13:14:37Z

Akoradh: /* Mediator Pattern and Facade Pattern */

=Introduction =

== Facade Pattern <ref>[http://sourcemaking.com/design_patterns/facade]</ref>==

Facade Pattern provides a unified interface to a set of interfaces in a subsystem. It wraps 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 <ref>[http://sourcemaking.com/design_patterns/adapter]</ref> ==

Adapter Pattern converts the interface of a class into another interface clients expect. Adapter lets classes work together that couldn’t otherwise because of incompatible interfaces. It wraps an existing class with a new interface. It aims to match an old component to a new system. It strives to convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn't otherwise because of incompatible interfaces.

== Abstract Factory Pattern <ref>[http://sourcemaking.com/design_patterns/abstract_factory]</ref> ==

Abstract Factory Pattern provides an interface for creating families of related or dependent objects without specifying their concrete classes. It defines a hierarchy that encapsulates: many possible “platforms”, and the construction of a suite of “products”. 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 <ref>[http://sourcemaking.com/design_patterns/mediator]</ref> ==

Mediator Pattern defines 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. It aims to design an intermediary to decouple many peers. It promotes 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 class is a wrapper which modifies an existing class. It provides an alternate view of that class. In cases where a third party component is readily available and provides functionality that needs to be used, but the interfaces exposed by the component does not have an exact match with the system that is being developed, adapter classes can be used. The mismatch can be diverse such as the way arguments are handled, some assumptions about the underlying implementations, physical dimensions, misalignment, timing or synchronization etc. 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 Pattern creates an intermediate class that maps the one component to other. The calls to methods on the Adapter object is redirected by the adapter 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, in the Facade example, assume that the user of OrderFacade needs to obtain order id in a different representation. To handle such scenario, a new adapter class OrderFacadeAdapter is defined. It implements all the methods of the OrderFacade and in each method where order id is referenced, it makes necessary changes to convert order id from one form to other and invoke other methods of the subsystem.

== Example ==
<pre>
public Class OrderFacadeAdapter {
public OrderId placeOrder(...) {
//convert order id from int to type 'OrderId' and return
}
}
</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 ==
<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 <ref>[http://stackoverflow.com/questions/481984/facade-vs-mediator]</ref> =
Mediator Pattern is used to avoid the direct dependencies between reusable pieces of software i.e if one of the components changes, then all components which are directly connected to it changes. One of the important example is the resources permission in unix. There are three categories of permissions - owner, group and others. Some users with similar characteristics are formed into a group. 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. 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]]

== Facade Example ==
<pre>
class Logger {
public void initLogger( String loggerName ) {
//generate a file logger. Create file if not found. Initialize
}
public void log( String message ) {
//call the file logger's log method
}
}
</pre>

The log functionality is provided by the file logger. The class Logger hides the handling of files, deletion of files etc. The init method creates a file if not present, defines the size of the file before roll over, initializes some state of Logger. Logger internally calls file logger's log method. It does not define a new functionality. It delegates to existing objects.

== Mediator Example ==
<pre>
public void initLogger( String loggerName ) {
//based on some global parameters, set logger as either file or socket or both
}

public void log( String message ) {
//depending on the initialization in initLogger, log the message to a file or socket or both.
//handle file input-ouput and socket input-ouput/
}
</pre>

In above example, depending on the initialization, the log methods handles the logging of message to either a file or socket or both. It has to have functionality to handle input and output to both file and socket.

== Differences and Similarities ==
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). Facade is an structural pattern, that is it describes the composition of the objects, while the mediator is an behavioral, that is , it describes the way the objects interact.

=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
* http://stackoverflow.com/questions/481984/facade-vs-mediator

CSC/ECE 517 Fall 2012/ch2b 2w42 aa

2012-11-20T13:13:22Z

Akoradh: /* Introduction */

=Introduction =

== Facade Pattern <ref>[http://sourcemaking.com/design_patterns/facade]</ref>==

Facade Pattern provides a unified interface to a set of interfaces in a subsystem. It wraps 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 <ref>[http://sourcemaking.com/design_patterns/adapter]</ref> ==

Adapter Pattern converts the interface of a class into another interface clients expect. Adapter lets classes work together that couldn’t otherwise because of incompatible interfaces. It wraps an existing class with a new interface. It aims to match an old component to a new system. It strives to convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn't otherwise because of incompatible interfaces.

== Abstract Factory Pattern <ref>[http://sourcemaking.com/design_patterns/abstract_factory]</ref> ==

Abstract Factory Pattern provides an interface for creating families of related or dependent objects without specifying their concrete classes. It defines a hierarchy that encapsulates: many possible “platforms”, and the construction of a suite of “products”. 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 <ref>[http://sourcemaking.com/design_patterns/mediator]</ref> ==

Mediator Pattern defines 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. It aims to design an intermediary to decouple many peers. It promotes 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 class is a wrapper which modifies an existing class. It provides an alternate view of that class. In cases where a third party component is readily available and provides functionality that needs to be used, but the interfaces exposed by the component does not have an exact match with the system that is being developed, adapter classes can be used. The mismatch can be diverse such as the way arguments are handled, some assumptions about the underlying implementations, physical dimensions, misalignment, timing or synchronization etc. 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 Pattern creates an intermediate class that maps the one component to other. The calls to methods on the Adapter object is redirected by the adapter 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, in the Facade example, assume that the user of OrderFacade needs to obtain order id in a different representation. To handle such scenario, a new adapter class OrderFacadeAdapter is defined. It implements all the methods of the OrderFacade and in each method where order id is referenced, it makes necessary changes to convert order id from one form to other and invoke other methods of the subsystem.

== Example ==
<pre>
public Class OrderFacadeAdapter {
public OrderId placeOrder(...) {
//convert order id from int to type 'OrderId' and return
}
}
</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 ==
<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=
Mediator Pattern is used to avoid the direct dependencies between reusable pieces of software i.e if one of the components changes, then all components which are directly connected to it changes. One of the important example is the resources permission in unix. There are three categories of permissions - owner, group and others. Some users with similar characteristics are formed into a group. 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. 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]]

== Facade Example ==
<pre>
class Logger {
public void initLogger( String loggerName ) {
//generate a file logger. Create file if not found. Initialize
}
public void log( String message ) {
//call the file logger's log method
}
}
</pre>

The log functionality is provided by the file logger. The class Logger hides the handling of files, deletion of files etc. The init method creates a file if not present, defines the size of the file before roll over, initializes some state of Logger. Logger internally calls file logger's log method. It does not define a new functionality. It delegates to existing objects.

== Mediator Example ==
<pre>
public void initLogger( String loggerName ) {
//based on some global parameters, set logger as either file or socket or both
}

public void log( String message ) {
//depending on the initialization in initLogger, log the message to a file or socket or both.
//handle file input-ouput and socket input-ouput/
}
</pre>

In above example, depending on the initialization, the log methods handles the logging of message to either a file or socket or both. It has to have functionality to handle input and output to both file and socket.

== Differences and Similarities ==
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). Facade is an structural pattern, that is it describes the composition of the objects, while the mediator is an behavioral, that is , it describes the way the objects interact.

=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
* http://stackoverflow.com/questions/481984/facade-vs-mediator

CSC/ECE 517 Fall 2012/ch2b 2w42 aa

2012-11-20T12:58:58Z

Akoradh: /* Mediator 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<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 class is a wrapper which modifies an existing class. It provides an alternate view of that class. In cases where a third party component is readily available and provides functionality that needs to be used, but the interfaces exposed by the component does not have an exact match with the system that is being developed, adapter classes can be used. The mismatch can be diverse such as the way arguments are handled, some assumptions about the underlying implementations, physical dimensions, misalignment, timing or synchronization etc. 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 Pattern creates an intermediate class that maps the one component to other. The calls to methods on the Adapter object is redirected by the adapter 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, in the Facade example, assume that the user of OrderFacade needs to obtain order id in a different representation. To handle such scenario, a new adapter class OrderFacadeAdapter is defined. It implements all the methods of the OrderFacade and in each method where order id is referenced, it makes necessary changes to convert order id from one form to other and invoke other methods of the subsystem.

== Example ==
<pre>
public Class OrderFacadeAdapter {
public OrderId placeOrder(...) {
//convert order id from int to type 'OrderId' and return
}
}
</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 ==
<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=
Mediator Pattern is used to avoid the direct dependencies between reusable pieces of software i.e if one of the components changes, then all components which are directly connected to it changes. One of the important example is the resources permission in unix. There are three categories of permissions - owner, group and others. Some users with similar characteristics are formed into a group. 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. 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]]

== Facade Example ==
<pre>
class Logger {
public void initLogger( String loggerName ) {
//generate a file logger. Create file if not found. Initialize
}
public void log( String message ) {
//call the file logger's log method
}
}
</pre>

The log functionality is provided by the file logger. The class Logger hides the handling of files, deletion of files etc. The init method creates a file if not present, defines the size of the file before roll over, initializes some state of Logger. Logger internally calls file logger's log method. It does not define a new functionality. It delegates to existing objects.

== Mediator Example ==
<pre>
public void initLogger( String loggerName ) {
//based on some global parameters, set logger as either file or socket or both
}

public void log( String message ) {
//depending on the initialization in initLogger, log the message to a file or socket or both.
//handle file input-ouput and socket input-ouput/
}
</pre>

In above example, depending on the initialization, the log methods handles the logging of message to either a file or socket or both. It has to have functionality to handle input and output to both file and socket.

== Differences and Similarities ==
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). Facade is an structural pattern, that is it describes the composition of the objects, while the mediator is an behavioral, that is , it describes the way the objects interact.

=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
* http://stackoverflow.com/questions/481984/facade-vs-mediator

CSC/ECE 517 Fall 2012/ch2b 2w42 aa

2012-11-20T12:55:57Z

Akoradh: /* Facade 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<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 class is a wrapper which modifies an existing class. It provides an alternate view of that class. In cases where a third party component is readily available and provides functionality that needs to be used, but the interfaces exposed by the component does not have an exact match with the system that is being developed, adapter classes can be used. The mismatch can be diverse such as the way arguments are handled, some assumptions about the underlying implementations, physical dimensions, misalignment, timing or synchronization etc. 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 Pattern creates an intermediate class that maps the one component to other. The calls to methods on the Adapter object is redirected by the adapter 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, in the Facade example, assume that the user of OrderFacade needs to obtain order id in a different representation. To handle such scenario, a new adapter class OrderFacadeAdapter is defined. It implements all the methods of the OrderFacade and in each method where order id is referenced, it makes necessary changes to convert order id from one form to other and invoke other methods of the subsystem.

== Example ==
<pre>
public Class OrderFacadeAdapter {
public OrderId placeOrder(...) {
//convert order id from int to type 'OrderId' and return
}
}
</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 ==
<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=
Mediator Pattern is used to avoid the direct dependencies between reusable pieces of software i.e if one of the components changes, then all components which are directly connected to it changes. One of the important example is the resources permission in unix. There are three categories of permissions - owner, group and others. Some users with similar characteristics are formed into a group. 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. 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]]

== Facade Example ==
<pre>
class Logger {
public void initLogger( String loggerName ) {
//generate a file logger. Create file if not found. Initialize
}
public void log( String message ) {
//call the file logger's log method
}
}
</pre>

The log functionality is provided by the file logger. The class Logger hides the handling of files, deletion of files etc. The init method creates a file if not present, defines the size of the file before roll over, initializes some state of Logger. Logger internally calls file logger's log method. It does not define a new functionality. It delegates to existing objects.

== Mediator Example ==
<pre>
public void initLogger( String loggerName ) {
this.loggerName = loggerName;
if ( loggerName == "someLogger" ) {
out = new PrintStream( new File("app.log"));
} else if ( loggerName == "serverLog" ) {
client = new Socket("127.0.0.1", 1234 );
} else if( loggerName == "dblog") {
dbConnection = Class.forName()... .
}

}

public void debug( String message ) {

if ( loggerName == "someLogger" ) {
out.println( message );
} else if ( loggerName == "serverLog" ) {
ObjectOutputStrewam oos =
new ObjectOutputStrewam( client.getOutputStream());
oos.writeObject( message );
} else if( loggerName == "dblog") {
Pstmt pstmt = dbConnection.prepareStatment( LOG_SQL );
pstmt.setParameter(1, message );
pstmt.executeUpdate();
dbConnection.commit();
}
}
</pre>

In this code, the mediator is the one that contains the business logic to create the appropriate "channel" to log and also to make the log into that channel. He is "creating" the functionality

== Differences and Similarities ==
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). Facade is an structural pattern, that is it describes the composition of the objects, while the mediator is an behavioral, that is , it describes the way the objects interact.

=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
* http://stackoverflow.com/questions/481984/facade-vs-mediator

CSC/ECE 517 Fall 2012/ch2b 2w42 aa

2012-11-20T12:48:19Z

Akoradh: /* 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<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 class is a wrapper which modifies an existing class. It provides an alternate view of that class. In cases where a third party component is readily available and provides functionality that needs to be used, but the interfaces exposed by the component does not have an exact match with the system that is being developed, adapter classes can be used. The mismatch can be diverse such as the way arguments are handled, some assumptions about the underlying implementations, physical dimensions, misalignment, timing or synchronization etc. 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 Pattern creates an intermediate class that maps the one component to other. The calls to methods on the Adapter object is redirected by the adapter 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, in the Facade example, assume that the user of OrderFacade needs to obtain order id in a different representation. To handle such scenario, a new adapter class OrderFacadeAdapter is defined. It implements all the methods of the OrderFacade and in each method where order id is referenced, it makes necessary changes to convert order id from one form to other and invoke other methods of the subsystem.

== Example ==
<pre>
public Class OrderFacadeAdapter {
public OrderId placeOrder(...) {
//convert order id from int to type 'OrderId' and return
}
}
</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 ==
<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=
Mediator Pattern is used to avoid the direct dependencies between reusable pieces of software i.e if one of the components changes, then all components which are directly connected to it changes. One of the important example is the resources permission in unix. There are three categories of permissions - owner, group and others. Some users with similar characteristics are formed into a group. 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. 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]]

== Facade Example ==
<pre>
class Logger {

private LoggerImpl internalLogger;
private LoggerManager manager;

public void initLogger( String loggerName ) {
this.internalLogger = manager.getLogger( loggerName );
}

public void debug( String message ) {
this.internalLogger.debug( message );
}
}
</pre>

The functionality already exist. The facade only hides it. In this hypothetical case, the LoggerManager handles the creation of the correct logger, and the LoggerImpl is a package private object that has the "debug" method. This way the Facade is not adding functionality he is just delegating to some existing objects.

== Mediator Example ==
<pre>
public void initLogger( String loggerName ) {
this.loggerName = loggerName;
if ( loggerName == "someLogger" ) {
out = new PrintStream( new File("app.log"));
} else if ( loggerName == "serverLog" ) {
client = new Socket("127.0.0.1", 1234 );
} else if( loggerName == "dblog") {
dbConnection = Class.forName()... .
}

}

public void debug( String message ) {

if ( loggerName == "someLogger" ) {
out.println( message );
} else if ( loggerName == "serverLog" ) {
ObjectOutputStrewam oos =
new ObjectOutputStrewam( client.getOutputStream());
oos.writeObject( message );
} else if( loggerName == "dblog") {
Pstmt pstmt = dbConnection.prepareStatment( LOG_SQL );
pstmt.setParameter(1, message );
pstmt.executeUpdate();
dbConnection.commit();
}
}
</pre>

In this code, the mediator is the one that contains the business logic to create the appropriate "channel" to log and also to make the log into that channel. He is "creating" the functionality

== Differences and Similarities ==
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). Facade is an structural pattern, that is it describes the composition of the objects, while the mediator is an behavioral, that is , it describes the way the objects interact.

=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
* http://stackoverflow.com/questions/481984/facade-vs-mediator

CSC/ECE 517 Fall 2012/ch2b 2w42 aa

2012-11-20T12:47:24Z

Akoradh: /* 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 class is a wrapper which modifies an existing class. It provides an alternate view of that class. In cases where a third party component is readily available and provides functionality that needs to be used, but the interfaces exposed by the component does not have an exact match with the system that is being developed, adapter classes can be used. The mismatch can be diverse such as the way arguments are handled, some assumptions about the underlying implementations, physical dimensions, misalignment, timing or synchronization etc. 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 Pattern creates an intermediate class that maps the one component to other. The calls to methods on the Adapter object is redirected by the adapter 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, in the Facade example, assume that the user of OrderFacade needs to obtain order id in a different representation. To handle such scenario, a new adapter class OrderFacadeAdapter is defined. It implements all the methods of the OrderFacade and in each method where order id is referenced, it makes necessary changes to convert order id from one form to other and invoke other methods of the subsystem.

== Example ==
<pre>
public Class OrderFacadeAdapter {
public OrderId placeOrder(...) {
//convert order id from int to type 'OrderId' and return
}
}
</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 ==
<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=
Mediator Pattern is used to avoid the direct dependencies between reusable pieces of software i.e if one of the components changes, then all components which are directly connected to it changes. One of the important example is the resources permission in unix. There are three categories of permissions - owner, group and others. Some users with similar characteristics are formed into a group. 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. 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]]

== Facade Example ==
<pre>
class Logger {

private LoggerImpl internalLogger;
private LoggerManager manager;

public void initLogger( String loggerName ) {
this.internalLogger = manager.getLogger( loggerName );
}

public void debug( String message ) {
this.internalLogger.debug( message );
}
}
</pre>

The functionality already exist. The facade only hides it. In this hypothetical case, the LoggerManager handles the creation of the correct logger, and the LoggerImpl is a package private object that has the "debug" method. This way the Facade is not adding functionality he is just delegating to some existing objects.

== Mediator Example ==
<pre>
public void initLogger( String loggerName ) {
this.loggerName = loggerName;
if ( loggerName == "someLogger" ) {
out = new PrintStream( new File("app.log"));
} else if ( loggerName == "serverLog" ) {
client = new Socket("127.0.0.1", 1234 );
} else if( loggerName == "dblog") {
dbConnection = Class.forName()... .
}

}

public void debug( String message ) {

if ( loggerName == "someLogger" ) {
out.println( message );
} else if ( loggerName == "serverLog" ) {
ObjectOutputStrewam oos =
new ObjectOutputStrewam( client.getOutputStream());
oos.writeObject( message );
} else if( loggerName == "dblog") {
Pstmt pstmt = dbConnection.prepareStatment( LOG_SQL );
pstmt.setParameter(1, message );
pstmt.executeUpdate();
dbConnection.commit();
}
}
</pre>

In this code, the mediator is the one that contains the business logic to create the appropriate "channel" to log and also to make the log into that channel. He is "creating" the functionality

== Differences and Similarities ==
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). Facade is an structural pattern, that is it describes the composition of the objects, while the mediator is an behavioral, that is , it describes the way the objects interact.

=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-20T12:46:53Z

Akoradh: /* 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<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 class is a wrapper which modifies an existing class. It provides an alternate view of that class. In cases where a third party component is readily available and provides functionality that needs to be used, but the interfaces exposed by the component does not have an exact match with the system that is being developed, adapter classes can be used. The mismatch can be diverse such as the way arguments are handled, some assumptions about the underlying implementations, physical dimensions, misalignment, timing or synchronization etc. 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 Pattern creates an intermediate class that maps the one component to other. The calls to methods on the Adapter object is redirected by the adapter 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, in the Facade example, assume that the user of OrderFacade needs to obtain order id in a different representation. To handle such scenario, a new adapter class OrderFacadeAdapter is defined. It implements all the methods of the OrderFacade and in each method where order id is referenced, it makes necessary changes to convert order id from one form to other and invoke other methods of the subsystem.

== Example ==
<pre>
public Class OrderFacadeAdapter {
public OrderId placeOrder(...) {
//convert order id from int to type 'OrderId' and return
}
}
</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=
Mediator Pattern is used to avoid the direct dependencies between reusable pieces of software i.e if one of the components changes, then all components which are directly connected to it changes. One of the important example is the resources permission in unix. There are three categories of permissions - owner, group and others. Some users with similar characteristics are formed into a group. 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. 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]]

== Facade Example ==
<pre>
class Logger {

private LoggerImpl internalLogger;
private LoggerManager manager;

public void initLogger( String loggerName ) {
this.internalLogger = manager.getLogger( loggerName );
}

public void debug( String message ) {
this.internalLogger.debug( message );
}
}
</pre>

The functionality already exist. The facade only hides it. In this hypothetical case, the LoggerManager handles the creation of the correct logger, and the LoggerImpl is a package private object that has the "debug" method. This way the Facade is not adding functionality he is just delegating to some existing objects.

== Mediator Example ==
<pre>
public void initLogger( String loggerName ) {
this.loggerName = loggerName;
if ( loggerName == "someLogger" ) {
out = new PrintStream( new File("app.log"));
} else if ( loggerName == "serverLog" ) {
client = new Socket("127.0.0.1", 1234 );
} else if( loggerName == "dblog") {
dbConnection = Class.forName()... .
}

}

public void debug( String message ) {

if ( loggerName == "someLogger" ) {
out.println( message );
} else if ( loggerName == "serverLog" ) {
ObjectOutputStrewam oos =
new ObjectOutputStrewam( client.getOutputStream());
oos.writeObject( message );
} else if( loggerName == "dblog") {
Pstmt pstmt = dbConnection.prepareStatment( LOG_SQL );
pstmt.setParameter(1, message );
pstmt.executeUpdate();
dbConnection.commit();
}
}
</pre>

In this code, the mediator is the one that contains the business logic to create the appropriate "channel" to log and also to make the log into that channel. He is "creating" the functionality

== Differences and Similarities ==
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). Facade is an structural pattern, that is it describes the composition of the objects, while the mediator is an behavioral, that is , it describes the way the objects interact.

=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-20T12:46:24Z

Akoradh: /* Mediator 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 class is a wrapper which modifies an existing class. It provides an alternate view of that class. In cases where a third party component is readily available and provides functionality that needs to be used, but the interfaces exposed by the component does not have an exact match with the system that is being developed, adapter classes can be used. The mismatch can be diverse such as the way arguments are handled, some assumptions about the underlying implementations, physical dimensions, misalignment, timing or synchronization etc. 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 Pattern creates an intermediate class that maps the one component to other. The calls to methods on the Adapter object is redirected by the adapter 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, in the Facade example, assume that the user of OrderFacade needs to obtain order id in a different representation. To handle such scenario, a new adapter class OrderFacadeAdapter is defined. It implements all the methods of the OrderFacade and in each method where order id is referenced, it makes necessary changes to convert order id from one form to other and invoke other methods of the subsystem.

== Example ==
<pre>
public Class OrderFacadeAdapter {
public OrderId placeOrder(...) {
//convert order id from int to type 'OrderId' and return
}
}
</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=
Mediator Pattern is used to avoid the direct dependencies between reusable pieces of software i.e if one of the components changes, then all components which are directly connected to it changes. One of the important example is the resources permission in unix. There are three categories of permissions - owner, group and others. Some users with similar characteristics are formed into a group. 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. 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]]

== Facade Example ==
<pre>
class Logger {

private LoggerImpl internalLogger;
private LoggerManager manager;

public void initLogger( String loggerName ) {
this.internalLogger = manager.getLogger( loggerName );
}

public void debug( String message ) {
this.internalLogger.debug( message );
}
}
</pre>

The functionality already exist. The facade only hides it. In this hypothetical case, the LoggerManager handles the creation of the correct logger, and the LoggerImpl is a package private object that has the "debug" method. This way the Facade is not adding functionality he is just delegating to some existing objects.

== Mediator Example ==
<pre>
public void initLogger( String loggerName ) {
this.loggerName = loggerName;
if ( loggerName == "someLogger" ) {
out = new PrintStream( new File("app.log"));
} else if ( loggerName == "serverLog" ) {
client = new Socket("127.0.0.1", 1234 );
} else if( loggerName == "dblog") {
dbConnection = Class.forName()... .
}

}

public void debug( String message ) {

if ( loggerName == "someLogger" ) {
out.println( message );
} else if ( loggerName == "serverLog" ) {
ObjectOutputStrewam oos =
new ObjectOutputStrewam( client.getOutputStream());
oos.writeObject( message );
} else if( loggerName == "dblog") {
Pstmt pstmt = dbConnection.prepareStatment( LOG_SQL );
pstmt.setParameter(1, message );
pstmt.executeUpdate();
dbConnection.commit();
}
}
</pre>

In this code, the mediator is the one that contains the business logic to create the appropriate "channel" to log and also to make the log into that channel. He is "creating" the functionality

== Differences and Similarities ===
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). Facade is an structural pattern, that is it describes the composition of the objects, while the mediator is an behavioral, that is , it describes the way the objects interact.

=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:51:16Z

Akoradh: /* Mediator 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 class is a wrapper which modifies an existing class. It provides an alternate view of that class. In cases where a third party component is readily available and provides functionality that needs to be used, but the interfaces exposed by the component does not have an exact match with the system that is being developed, adapter classes can be used. The mismatch can be diverse such as the way arguments are handled, some assumptions about the underlying implementations, physical dimensions, misalignment, timing or synchronization etc. 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 Pattern creates an intermediate class that maps the one component to other. The calls to methods on the Adapter object is redirected by the adapter 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, in the Facade example, assume that the user of OrderFacade needs to obtain order id in a different representation. To handle such scenario, a new adapter class OrderFacadeAdapter is defined. It implements all the methods of the OrderFacade and in each method where order id is referenced, it makes necessary changes to convert order id from one form to other and invoke other methods of the subsystem.

== Example ==
<pre>
public Class OrderFacadeAdapter {
public OrderId placeOrder(...) {
//convert order id from int to type 'OrderId' and return
}
}
</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=
Mediator Pattern is used to avoid the direct dependencies between reusable pieces of software i.e if one of the components changes, then all components which are directly connected to it changes. One of the important example is the resources permission in unix. There are three categories of permissions - owner, group and others. Some users with similar characteristics are formed into a group. 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. 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:40:22Z

Akoradh: /* Adapter 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 class is a wrapper which modifies an existing class. It provides an alternate view of that class. In cases where a third party component is readily available and provides functionality that needs to be used, but the interfaces exposed by the component does not have an exact match with the system that is being developed, adapter classes can be used. The mismatch can be diverse such as the way arguments are handled, some assumptions about the underlying implementations, physical dimensions, misalignment, timing or synchronization etc. 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 Pattern creates an intermediate class that maps the one component to other. The calls to methods on the Adapter object is redirected by the adapter 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, in the Facade example, assume that the user of OrderFacade needs to obtain order id in a different representation. To handle such scenario, a new adapter class OrderFacadeAdapter is defined. It implements all the methods of the OrderFacade and in each method where order id is referenced, it makes necessary changes to convert order id from one form to other and invoke other methods of the subsystem.

== Example ==
<pre>
public Class OrderFacadeAdapter {
public OrderId placeOrder(...) {
//convert order id from int to type 'OrderId' and return
}
}
</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:39:32Z

Akoradh: /* 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<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, in the Facade example, assume that the user of OrderFacade needs to obtain order id in a different representation. To handle such scenario, a new adapter class OrderFacadeAdapter is defined. It implements all the methods of the OrderFacade and in each method where order id is referenced, it makes necessary changes to convert order id from one form to other and invoke other methods of the subsystem.

== Example ==
<pre>
public Class OrderFacadeAdapter {
public OrderId placeOrder(...) {
//convert order id from int to type 'OrderId' and return
}
}
</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:39:10Z

Akoradh: /* Adapter 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<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, in the Facade example, assume that the user of OrderFacade needs to obtain order id in a different representation. To handle such scenario, a new adapter class OrderFacadeAdapter is defined. It implements all the methods of the OrderFacade and in each method where order id is referenced, it makes necessary changes to convert order id from one form to other and invoke other methods of the subsystem.

== Example ==
<pre>
public Class OrderFacadeAdapter {
public OrderId placeOrder(...) {
//convert order id from int to type 'OrderId' and return
}
}
</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:38:34Z

Akoradh: /* 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<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 OrderFacadeAdapter {
public OrderId placeOrder(...) {
//convert order id from int to type 'OrderId' and return
}
}
</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-20T00:32:09Z

Akoradh: /* Differences and similarities between Adapter and Facade */

=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:31:49Z

Akoradh: /* Mediator 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 between Adapter and Facade ==
* 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:27Z

Akoradh: /* Differences n similarities between Adapter and Facade */

=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 between Adapter and Facade ==
* 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).

CSC/ECE 517 Fall 2012/ch2b 2w42 aa

2012-11-20T00:30:16Z

Akoradh: /* Adapter 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 n similarities between Adapter and Facade ==
* 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).

CSC/ECE 517 Fall 2012/ch2b 2w42 aa

2012-11-20T00:28:52Z

Akoradh: /* Differences n similarities between Adapter and Facade */

=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]]

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:28:30Z

Akoradh: /* Mediator 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>

=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]]

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).

=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:28:00Z

Akoradh: /* Mediator 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>

=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]]

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.

=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:26:25Z

Akoradh: /* Mediator Pattern and Facade Pattern */

File:Mediator 1.gif

2012-11-20T00:24:39Z

Akoradh:

CSC/ECE 517 Fall 2012/ch2b 2w42 aa

2012-11-20T00:21:59Z

Akoradh: /* Mediator Pattern and Facade Pattern */

CSC/ECE 517 Fall 2012/ch2b 2w42 aa

2012-11-20T00:19:15Z

Akoradh: /* Mediator Pattern and Facade Pattern */

CSC/ECE 517 Fall 2012/ch2b 2w42 aa

2012-11-20T00:15:10Z

Akoradh: /* Mediator Pattern */

CSC/ECE 517 Fall 2012/ch2b 2w42 aa

2012-11-20T00:13:22Z

Akoradh: /* Adapter Pattern and Facade Pattern */

CSC/ECE 517 Fall 2012/ch2b 2w42 aa

2012-11-19T23:36:54Z

Akoradh: /* Adapter Pattern Example */

CSC/ECE 517 Fall 2012/ch2b 2w42 aa

2012-11-19T23:31:54Z

Akoradh: /* Adapter Pattern Example */

CSC/ECE 517 Fall 2012/ch2b 2w42 aa

2012-11-19T23:13:00Z

Akoradh: /* Mediator Pattern */

CSC/ECE 517 Fall 2012/ch2b 2w42 aa

2012-11-19T23:12:49Z

Akoradh: /* Abstract Factory Pattern */

CSC/ECE 517 Fall 2012/ch2b 2w42 aa

2012-11-19T23:12:13Z

Akoradh: /* Adapter Pattern */

CSC/ECE 517 Fall 2012/ch2b 2w42 aa

2012-11-19T22:55:05Z

Akoradh: /* Adapter Pattern */

CSC/ECE 517 Fall 2012/ch2b 2w42 aa

2012-11-19T22:44:32Z

Akoradh: /* example */

CSC/ECE 517 Fall 2012/ch2b 2w42 aa

2012-11-19T22:44:03Z

Akoradh: /* example */

CSC/ECE 517 Fall 2012/ch2b 2w42 aa

2012-11-19T22:42:47Z

Akoradh: /* example */

CSC/ECE 517 Fall 2012/ch2b 2w42 aa

2012-11-19T22:41:09Z

Akoradh:

CSC/ECE 517 Fall 2012/ch2b 2w42 aa

2012-11-19T22:40:35Z

Akoradh:

CSC/ECE 517 Fall 2012/ch2b 2w42 aa

2012-11-19T20:21:07Z

Akoradh:

CSC/ECE 517 Fall 2012/ch2b 2w42 aa

2012-11-19T20:17:07Z

Akoradh:

=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. 

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 ==
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. 

==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. 

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==

=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.

[[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 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 =

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.

=Abstract Factory Pattern =

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. 

=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-19T20:06:23Z

Akoradh:

=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. 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.

[[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-19T01:40:46Z

Akoradh:

CSC/ECE 517 Fall 2012/ch2b 2w42 aa

2012-11-19T01:37:01Z

Akoradh:

=Introduction =

==Facade Pattern==

==Abstract Factory Pattern==

==Mediator Pattern==

CSC/ECE 517 Fall 2012/ch2b 2w42 aa

2012-11-19T01:36:14Z

Akoradh:

=Introduction =

CSC/ECE 517 Fall 2012/ch2b 2w42 aa

2012-11-19T01:33:22Z

Akoradh: Created page with "2w42. Facade pattern and the related patterns (Adapter, Abstract Factory, Mediator)"

2w42. Facade pattern and the related patterns (Adapter, Abstract Factory, Mediator)

CSC/ECE 517 Fall 2012

2012-11-19T01:32:53Z

Akoradh:

*[[CSC/ECE_517_Fall_2012/Table_Of_Contents]]
*[[CSC/ECE 517 Fall 2012/ch1 n xx]]
*[[CSC/ECE 517 Fall 2012/ch1 1w1 rk]]
*[[CSC/ECE 517 Fall 2012/ch1 1w20 pp]]
*[[CSC/ECE 517 Fall 2012/ch1 1w5 su]]
*[[CSC/ECE 517 Fall 2012/ch1 1w6 pp]]
*[[CSC/ECE 517 Fall 2012/ch1 1w4 aj]]
*[[CSC/ECE 517 Fall 2012/ch1 1w7 am]]
*[[CSC/ECE 517 Fall 2012/ch1 1w8 aa]]
*[[CSC/ECE 517 Fall 2012/ch1 1w9 av]]
*[[CSC/ECE 517 Fall 2012/ch1 1w10 pk]]
*[[CSC/ECE 517 Fall 2012/ch1 1w11 ap]]
*[[CSC/ECE 517 Fall 2012/ch1a 1w12 mv]]
*[[CSC/ECE 517 Fall 2012/ch1 1w14 gv]]
*[[CSC/ECE 517 Fall 2012/ch1 1w17 ir]]
*[[CSC/ECE 517 Fall 2012/ch1 1w18 as]]
*[[CSC/ECE 517 Fall 2012/ch1 1w22 an]]
*[[CSC/ECE 517 Fall 2012/ch1 1w21 aa]]
*[[CSC/ECE 517 Fall 2012/ch1 1w21 wi]]
*[[CSC/ECE 517 Fall 2012/ch1 1w31 sa]]
*[[CSC/ECE 517 Fall 2012/ch1a 1w16 br]]
*[[CSC/ECE 517 Fall 2012/ch1a 1w23 as]]
*[[CSC/ECE 517 Fall 2012/ch1 1w24 nr]]
*[[CSC/ECE 517 Fall 2012/ch1 1w15 rt]]
*[[CSC/ECE 517 Fall 2012/ch1 1w3 pl]]
*[[CSC/ECE 517 Fall 2012/ch1 1w32 cm]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w5 dp]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w37 ss]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w67 ks]]

*[[CSC/ECE 517 Fall 2012/ch1 1w27 ms]]
*[[CSC/ECE 517 Fall 2012/ch1 1w29 sa]]
*[[CSC/ECE 517 Fall 2012/ch1 1w33 op]]
*[[CSC/ECE 517 Fall 2012/ch1 1w19 sa]]
*[[CSC/ECE 517 Fall 2012/ch1 1w34 vd]]
*[[CSC/ECE 517 Fall 2012/ch1 1w35 sa]]
*[[CSC/ECE 517 Fall 2012/ch1 1w30 rp]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w58 am]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w47 sk]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w69 mv]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w44 as]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w45 is]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w53 kc]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w40 ar]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w39 sn]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w54 go]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w56 ms]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w64 nn]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w66 as]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w40 as]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w42 js]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w46 sm]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w71 gs]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w63 dv]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w55 ms]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w57 mp]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w52 an]]
*[[CSC/ECE_517_Fall_2012/ch1b 1w38 nm]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w60 ac]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w62 rb]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w29 st]]
*[[CSC/ECE_517_Fall_2012/ch2a_2w3_sm]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w30 an]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w17 pt]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w31 up]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w9 ms]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w19 is]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w26 aj]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w5 dp]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w16 dp]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w8 vp]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w18 as]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w3 jm]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w23 sr]]
*[[CSC/ECE_517_Fall_2012/ch2a_2w11_aa]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w15 rr]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w33 pv]]
*[[CSC/ECE_517_Fall_2012/ch2a_2w20_aa]]
*[[CSC/ECE_517_Fall_2012/ch2a_2w14_bb]]
*[[CSC/ECE_517_Fall_2012/ch2a_2w21_ap]]
*[[CSC/ECE_517_Fall_2012/ch2a_2w13_sm]]
*[[CSC/ECE_517_Fall_2012/ch2a_2w4_sa]]
*[[CSC/ECE_517_Fall_2012/ch2a_2w25_nr]]
*[[CSC/ECE_517_Fall_2012/ch2a_2w12_sv]]
*[[CSC/ECE_517_Fall_2012/ch2a_2w7_ma]]
*[[CSC/ECE_517_Fall_2012/ch2a_2w6_ar]]
*[[CSC/ECE_517_Fall_2012/ch2a_2w32_mk]]
*[[CSC/ECE_517_Fall_2012/ch2a_2w10_rc]]
*[[CSC/ECE 517 Fall 2012/ch2b_2w70_sm]]
*[[CSC/ECE 517 Fall 2012/ch2b_2w67_sk]]
*[[CSC/ECE 517 Fall 2012/ch2b_2w40_sn]]
*[[CSC/ECE 517 Fall 2012/ch2b_2w22_sk]]
*[[CSC/ECE 517 Fall 2012/ch2b_2w-1w65_am]]
*[[CSC/ECE 517 Fall 2012/ch2b_2w59_bc]]
*[[CSC/ECE 517 Fall 2012/ch2b_2w60_ns]]
*[[CSC/ECE 517 Fall 2012/ch2b 2w47 am]]
*[[CSC/ECE 517 Fall 2012/ch2b_2w69_as]]
*[[CSC/ECE 517 Fall 2012/ch2b_2w39_ka]]
*[[CSC/ECE 517 Fall 2012/ch2b_2w36_av]]
*[[CSC/ECE 517 Fall 2012/ch2b_2w37_ms]]
*[[CSC/ECE 517 Fall 2012/ch2b_2w43_iv]]
*[[CSC/ECE 517 Fall 2012/ch2b_2w53_iv]]
*[[CSC/ECE 517 Fall 2012/ch2b_2w63_sp]]
*[[CSC/ECE 517 Fall 2012/ch2b_2w49_ps]]
*[[CSC/ECE 517 Fall 2012/ch2b_2w52_sj]]
*[[CSC/ECE 517 Fall 2012/ch2b_2w28_dh]]
*[[CSC/ECE 517 Fall 2012/ch1b 2w41 dc]]
*[[CSC/ECE_517_Fall_2012/ch2b_1w59_nm]]
*[[CSC/ECE_517_Fall_2012/ch2b_1w61_ps]]
*[[CSC/ECE_517_Fall_2012/ch2b_2w57]]
*[[CSC/ECE_517_Fall_2012/ch2b_2w42_aa]]