According to the Gang of Four:
Façade Pattern provides a unified interface to a set of interfaces in a subsystem. Façade defines a higher-level interface that makes the subsystem easier to use.
Problem: You need to use only a subset of a complex system or you need to interact with the system in a particular way.
Solution: The facade presents a new interface for the client of the existing system to use.
We can implement this pattern for ”Data Access Application block” provided by Microsoft ® under Enterprise Library.
Why would you like to implement Façade pattern for predefined and already tested classes?
The problem that we faced with Data Access Application block that it is complex and a person who likes to use this block efficiently needs to understand structure.
<shape id="_x0000_i1026" style="WIDTH: 469.5pt; HEIGHT: 187.5pt" type="#_x0000_t75" o:allowoverlap="f"><imagedata src="file:///C:/DOCUME~1/amit/LOCALS~1/Temp/msoclip1/01/clip_image003.png">
[Data Access Application Block class diagram]
To reduce this complexity and time required to understand, we opt to define Wrapper of the component. This wrapper is merely a class, offering all operations through “Data Access Application Block”.
<shape id="_x0000_i1027" style="WIDTH: 6in; HEIGHT: 444pt" type="#_x0000_t75"><imagedata o:title="Facade Implementation for Data Access" src="file:///C:/DOCUME~1/amit/LOCALS~1/Temp/msoclip1/01/clip_image005.jpg">
Having this approach, we will get the following benefits:
- Understand “
DataAccessWrapper” class would suffix our requirement.
- DataAccessWrapper is the central place to communicate with Data Access component hence we can amend feature easily, such as logging, exception management.
Apart from that, we also implemented the feature that when an exception will occur, the wrapper will check if it can be recovered by running the query again.
- Block can be changed easily -> If there is any vast change in “Data Access Application Block”, it would be handy to change only the wrapper class and we're done.
Another practical example I came across is: “Managing ASP.NET session variable”, written by David Hay.
I am trying to show through the below diagram what it is all about. However, to read the original text, please visit this article.
<shape id="_x0000_i1028" style="WIDTH: 6in; HEIGHT: 352.5pt" type="#_x0000_t75"><imagedata o:title="Facade Pattern - Direct Access to HttpSessionState" src="file:///C:/DOCUME~1/amit/LOCALS~1/Temp/msoclip1/01/clip_image007.png">
Solution (with the help of Façade Pattern):
<shape id="_x0000_i1029" style="WIDTH: 6in; HEIGHT: 438.75pt" type="#_x0000_t75"><imagedata o:title="Facade Pattern - Implementation in HttpSessionState" src="file:///C:/DOCUME~1/amit/LOCALS~1/Temp/msoclip1/01/clip_image009.png">
- You don’t need to use all the functionality of a complex system and can create a new class that contains all the rules for accessing that system.
- You want to encapsulate or hide the original system.
- You want to use the functionality of the original system and want to add some new functionality as well.
- The cost of writing a new class is less expensive than the cost of everybody learning how to use the original system.
According to the Gang of Four:
Adapter Pattern: Convert the interface of a class into another interface that the clients expect. Adapter lets classes work together that could not otherwise because of incompatible interface.
Problem: A system has the right data and behavior but the wrong interface. Typically used when you have to make something a derivative of an
Solution: The Adapter provides a wrapper with the desired interface.
<shape id="_x0000_i1030" style="WIDTH: 6in; HEIGHT: 435.75pt" type="#_x0000_t75"><imagedata o:title="Adapter Pattern - Generic Structure" src="file:///C:/DOCUME~1/amit/LOCALS~1/Temp/msoclip1/01/clip_image011.png">
The easiest way to understand the intent of the Adapter pattern is to look at an example of where it is useful.
Let's say you want to use Infragistics control:
UltraWebGrid, for the presentation layer of the project but this control has not been released. However, Infragistics has provided you Interface and description of each function that would be available in their control.
By considering interface, you have spent a number of hours for the presentation layer development.
When Infragistics released controls, you identified that the function name given by them is different than what you have considered throughout the development.
<shape id="_x0000_i1031" style="WIDTH: 431.25pt; HEIGHT: 249pt" type="#_x0000_t75"><imagedata o:title="Adapter Pattern - Infragistics Problem" src="file:///C:/DOCUME~1/amit/LOCALS~1/Temp/msoclip1/01/clip_image013.png">
One solution would be to change your entire presentation layer, and correct function calls. But it would increase the cost of the product!
You talked with Infragistics and they apologize for not updating you. The System Architect at Infragistics suggests that they can provide
UltraWebGridAdapter so that there would be minimal changes in your project.
<shape id="_x0000_i1032" style="WIDTH: 431.25pt; HEIGHT: 249pt" type="#_x0000_t75"><imagedata o:title="Adapter Pattern - Infragistics Solution" src="file:///C:/DOCUME~1/amit/LOCALS~1/Temp/msoclip1/01/clip_image015.png">
What all you did is to create object of
UltraWebGridAdapter class, instead of
UltraWebGrid class and the rest is the same.
There are two types of Adapter patterns:
- Object Adapter pattern – The adapter pattern I have been using is called a object adapter because it relies on one object (the adapting object) containing another (the adapted object).
- Class Adapter pattern – Another way to implement the adapter pattern is with multiple inheritance, in this case it is called a class adapter pattern.
Comparing the façade pattern with the Adapter pattern:
|Are there existing classes?
|Is there an interface we must design to?
|Does an object need to behave polymorphically?
|Is a simpler interface needed?
Bottom Line: A façade simplifies an interface while an Adapter converts a pre-existing interface into another interface.
According to the Gang of Four:
Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it.
Problem: The selection of an algorithm that needs to be applied depends on the client making the request or the data being acted on. If you just have a rule in place that does not change, you don’t need a strategy pattern.
Solution: Separate the selection of an algorithm from the implementation of the algorithm. Allows for the selection to be made based upon context.
<shape id="_x0000_i1033" style="WIDTH: 431.25pt; HEIGHT: 254.25pt" type="#_x0000_t75"><imagedata o:title="Strategy Pattern - Generic Structure" src="file:///C:/DOCUME~1/amit/LOCALS~1/Temp/msoclip1/01/clip_image017.png">
Recently, I am working on a project for the international market. It is in .NET and we do know that .NET is rich to provide classes to handle this. However, we don’t want to use those classes directly. Because there may be the case that at given point in time, those classes are not sufficient to fulfill our requirement.
CompareInfo cannot be set in existing culture. However, if we create custom culture through “
CultureAndRegionInfoBuilder”, it would allow to specify
CompareInfo that was being used during comparison.
Here is what strategy pattern helped me to handle this requirement without affecting client side.
What we did is create an interface
IcultureFactory and each.
According to the Gang of Four, the intent of the bridge pattern is to “ decouple an abstraction from its implementation so that the two can vary independently.”
Problem: The derivations of an
abstract class must use multiple implementations without causing an explosion in the number of classes.
Solution: Define an interface for all implantations to use and have the derivations of the
abstract class use that.
<shape id="_x0000_i1034" style="WIDTH: 6in; HEIGHT: 288.75pt" type="#_x0000_t75"><imagedata o:title="Bridge Pattern - Generic Structure" src="file:///C:/DOCUME~1/amit/LOCALS~1/Temp/msoclip1/01/clip_image019.png">
Problem: Families of related objects need to be instantiated.
Solution: Coordinates the creation of families of objects. Gives a way to take the rules of how to perform the instantiation out of the client object that is using these created objects.
<shape id="_x0000_i1035" style="WIDTH: 431.25pt; HEIGHT: 326.25pt" type="#_x0000_t75"><imagedata o:title="Factory Pattern - Generic Structure" src="file:///C:/DOCUME~1/amit/LOCALS~1/Temp/msoclip1/01/clip_image021.png">