Daily Archives: April 9, 2014

Adapter pattern: Design Pattern Series – Part: 13

Adapter Pattern falls under Structural pattern:

According to the GoF, the intent of the Adapter pattern is,

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

Problem: 
Sometimes a toolkit or class library can not be used because its interface is  incompatible with the interface required by an application and We can not change the library interface,  since we may not have its source code. For example the below example uses the grid which have the Method called Fill. But lets say  at some point of time you might like to use Infragistics grid(3rd party) which is not having the method called “Fill”, for example, and you may not populate the Client object with the Infragistics grid because of this incompatibility.

Solution:
The solution is to create an InfragisticsAdapter(Who Adapts the adaptee to client – pattern) which composes the Adaptee(Infragistics) and the InfragisticsAdapter will be compatible with the existing interface so that the client can be populated with Adapter.

Please find below the UML for this pattern:

adpater

The UML class diagram above describes an implementation of the adapter design pattern. The items in the diagram are described below:

 Client: The client class is that which requires the use of an incompatible type. It expects to interact with a type that implements the ITarget interface. However, the class that we wish it to use is the incompatible Adaptee.
 ITarget: This is the expected interface for the client class. Although shown in the diagram as an interface, it may be a class that the adapter inherits. If a class is used, the adapter must override its members.
 Adaptee: This class contains the functionality that is required by the client. However, its interface is not compatible with that which is expected.
 Adapter: This class provides the link between the incompatible Client and Adaptee classes. The adapter implements the ITarget interface and contains a private instance of the Adaptee class. When the client executes MethodA on the ITarget interface, MethodA in the adapter translates this request to a call to MethodB on the internal Adaptee instance.

Example:

public class Client
{
   
    public Client(IGrid  iGrid)
    {
        this.iGrid = iGrid;
 } 
 private IGrid iGrid;
 
    public void PopulateGrid(DataSet ds)
    {
        iGrid.Fill(ds);
    }
}
 
 
public interface IGrid
{
    void Fill(DataSet ds);
}
 
 
public class Infragistics
{
    public void DataFill(DataSet ds)
    {
        // fill the data into grid.
    }
}

public class InfragisticsAdapter : IGrid
{
    Infragistics _adaptee = new Infragistics();
 
    public void Fill(DataSet ds)
    {
        _adaptee.DataFill(ds);
    }
}

public void static Main()
{
 var client = new Client(new InfragisticsAdapter());
 var ds = GetDataset();
 client.PopulateGrid(ds); //– Hurray it will now work.
}

Rules of thumb
* Adapter makes things work after they’re designed; Bridge makes them work before they are.
* Bridge is designed up-front to let the abstraction and the implementation vary independently. Adapter is retrofitted to   make unrelated classes work together.
* Adapter provides a different interface to its subject. Proxy provides the same interface. Decorator provides an enhanced   interface.
* Adapter is meant to change the interface of an existing object. Decorator enhances another object without changing its   interface. Decorator is thus more transparent to the application than an adapter is. As a consequence, Decorator supports   recursive composition, which isn’t possible with pure Adapters.
* Facade defines a new interface, whereas Adapter reuses an old interface. Remember that Adapter makes two existing   interfaces work together as opposed to defining an entirely new one.

 

Proxy pattern: Design Pattern Series – Part: 12

Proxy Pattern falls under Structural pattern:

According to the GoF, the intent of the Proxy pattern is,

 Provide a surrogate or placeholder for another object to control access to it.

Problem:
 You need to support resource-hungry objects, and you do not want to instantiate such objects unless and until they are  actually requested by the client.

Solution:

 A Proxy can also be defined as a surrogate. In the real work a cheque or debit card is a proxy for what is in our bank account.  It can be used in place of cash, which is what is needed, and provides a means of accessing that cash when required. And that’s exactly what the Proxy pattern does – controls and manage access to the object they are “protecting”.

Please find below the UML for this pattern:

proxy

The participants classes in the proxy pattern are:

Subject – Interface implemented by the RealSubject and representing its services. The interface must be implemented by the proxy as well so that the proxy can be used in any location where the RealSubject can be used.

Proxy – Maintains a reference that allows the Proxy to access the RealSubject.
Implements the same interface implemented by the RealSubject so that the Proxy can be substituted for the RealSubject.
Controls access to the RealSubject and may be responsible for its creation and deletion.
Other responsibilities depend on the kind of proxy.

RealSubject – the real object that the proxy represents.

 

Example :

public interface Image {    // Subject Interface

 void showImage();
 
}

public class ImageProxy : Image { // Proxy Subject

 private String imageFilePath;
 
 private Image proxifiedImage;
 
 
 public ImageProxy(String imageFilePath) {
  this.imageFilePath= imageFilePath; 
 }
  
 public void showImage() {

  proxifiedImage = new HighResolutionImage(imageFilePath);
  
  // now call showImage on realSubject
  proxifiedImage.showImage();
  
 } }

public class HighResolutionImage : Image { // Real Subject

 public HighResolutionImage(String imageFilePath) {
  
  loadImage(imageFilePath);
 }

 private void loadImage(String imageFilePath) {

  // load Image from disk into memory
  // this is heavy and costly operation
 }

 
 public void showImage() {

  // Actual Image rendering logic

 } }

Rules of thumb:
* Adapter provides a different interface to its subject. Proxy provides the same interface. Decorator provides an enhanced  interface.
* Decorator and Proxy have different purposes but similar structures. Both describe how to provide a level of indirection  to another object, and the implementations keep a reference to the object to which they forward requests.

 

Abstract Factory pattern: Design Pattern Series – Part: 11

Abstract Factory falls under Creational Pattern:

According to the GoF, the intent of the Abstract Factory pattern is,

 Provide an interface for creating families of related or dependent objects without specifying their concrete classes.

Problem:
You have seen a factory method already. But in the real world, factory class will not be one and it could be many to produce appropriate family of objects. Lets say, In a car company, a particular factory can be used to create different doors (front, back, side., ) , for example DoorFactory. The same goes to different lights, seats etc., So here what we have is group of factories. The problem here is sometimes we need to create a particular factory among group of factories.
 

Solution:

So we abstract out factories and at runtime we are going to create desired concrete factory.

Please find below the UML for this pattern:

abstract

The classes and/or objects participating in this pattern are:

•AbstractFactory  (AnimalFactory) declares an interface for operations that create abstract products

•ConcreteFactory   (SeaFactory, LandFactory) implements the operations to create concrete product objects

•AbstractProduct   (Animal) declares an interface for a type of product object

•Product  (Lion, Fish) defines a product object to be created by the corresponding concrete factory
 implements the AbstractProduct interface

•Client  (AnimalWorld) uses interfaces declared by AbstractFactory and AbstractProduct classes

Example :

public interface AnimalFactory { // Abstrct Factory
  Animal createAnimal(string condition);
}

 public class SeaFactory : AnimalFactory { // Concrete Factory
   public Animal createAnimal(string condition) {

     if(condition == “S”)
       return new Shark();
     return new Fish();
  } 
}

public class LandFactory : AnimalFactory { // Concrete Factory

  public Animal createAnimal(string condition) {
     if(condition == “E”)
       return new Elephant();
     return new Lion();
  }
}

public class AnimalWorld
{
 public AnimalFactory GetAnimalFactory(string condition)
 {
    if(condition == “Land”)
       return new LandFactory ();
     return SeaFactory();
 }
}