Adapter Vs. Facade

[gautham kasinath]

Well, Started to learn the design patterns on my own and I m stuck with a hell a lotta problems..
Completed the Adapter and went on to Facade..
Adapter : Def. If you got this and you need that, Adapter comes to the rescue
So if we have a set of classes that know how to block a ticket, validate and charge a credit card and issue a ticket, and we want to make a reservation, Adapter comes to the rescue with a simple interface having method makeResevation!! Which inturn translates the calls to the underlying subsystem to realise what is needed..

Facade : provides a simple interface to a more complex subsystem..
From how I interpret it, in the above example, replacing the adapter with a facade also solves the same problem, changing the entire pattern in the course of it..
What is the design parameter that can be used to evaluate which pattern would fit and how??
Regds
Gautham Kasinath

[Ilja Preuss]

Originally posted by gautham kasinath:
[QB]Adapter : Def. If you got this and you need that, Adapter comes to the rescue
So if we have a set of classes that know how to block a ticket, validate and charge a credit card and issue a ticket, and we want to make a reservation, Adapter comes to the rescue with a simple interface having method makeResevation!! Which inturn translates the calls to the underlying subsystem to realise what is needed..

Sounds more like a Facade to me.
For an example of Adapter, suppose you are getting an Enumeration from an object, but need to pass an Iterator to another. The solution to this could be an Adapter which translates calls to the Iterator into calls to the Enumeration.
So a Facade typically differs from an Adapter in having to handle more complex collaborations than just delegating a simple request. The interface of an Adapter isn't necessarily any simpler than the interface of the class it is adapting. Other than that, they differ more in motivation than in implementation.
Does that help?
[ October 09, 2002: Message edited by: Ilja Preuss ]

[Wilfried LAURENT]

I agree with Ilja. They differ on the motivation
Shortly
Facade: hides the complexity of a subsystem or simplifies its interface.
Adapter: you want to use already existing classes but their interfaces do not match your need.
Another motivation of Adapter is to federate a family of already existing class into the same hierarchy (or to incorporate some classes to an already existing hierarchy).
For example, you get a client that manipulates Shapes (what a surprise ).
Somebody in your team has already for his own needs a Circle. Someone else a Rectangle and a Triangle. Of course they do not have the interface expected by the client.
So you have to adapt it, if you want to reuse it.

interface Shape {
 public void draw();
 public Point getPosition();
  }
public class Circle implements Shape {
  private OldCircle c= new OldCircle();
  public void draw() {
    c.drawCircle(); 
  } 
  public Point getPosition() { 
    int x = c.getX();
    int y  =c.getY();
    Point p= new Point(x,y);
    return p;
  }
  
}

and the same with Triangle and Rectangle.
W.

[Wilfried LAURENT]

I knew I had recently read something on it. It is A. Shalloway's Design Pattern Explained book (p.107). There is a chart comparing Facade (F)pattern with the Adapter (A):

Are there preexisting class? F: Yes A:Yes

Is there an interface we must design to? F:No A: Yes

Does an object need to behave polymorphically? F:No A: Probably

Is a simpler interface needed? F:Yes A:No

W.
[ October 10, 2002: Message edited by: Wilfried LAURENT ]
[ October 10, 2002: Message edited by: Wilfried LAURENT ]

[gautham kasinath]

tanx Wil. your chart really helped me understand the difference..
thanks verymuch.
Regds
Lupo

[Wilfried LAURENT]

I am not the one to thank but A. Shalloway