What's the difference and similarity between proxy and facade?

[Pankaj Halder]

GoF's book is too dry and abstract to analyze the difference and similarity between the two.

[Wirianto Djunaidi]

Somebody probably can give a more thorough answer. For me the quick guideline for those two are:

Similarities:
- structurally they are similar where you have the proxy / facade object in the front talking with the real [domain|implementataion|whatever] object at the back. This similarity also shared with Adaptor and Decorator pattern.

Since structurally all those patterns are similar or almost similar, the differences are based on intent or purpose of the patterns.

For Proxy and Facade:
- Proxy: typically to provide specific functionality that the user should not care or need to know the detail about. Some example: EJB proxy object, Spring transaction object, some of the AOP implementation use of proxy.
- Facade: On the other hand, facade is providing a different front or direct interface to the user. The purpose is to give a consistent or easier API for user to use without knowing the specific of how the overall implementation in the back end is handled. Common example is business facade. Concrete implementation example, E-bay might have a Facade Interface for buyer to bid an item, and at the back end it might be talking to multiple different modules to process the bid like inserting new bid transaction that ties to you, update the item auction bid order list, trigger notification for other bidders that previously registered to keep track of that item, etc.

[arulk pillai]

Facade: The fa�ade pattern provides an interface to large subsystems of classes. A common design goal is to minimize the communication and dependencies between subsystems. One way to achieve this goal is to introduce a fa�ade object that provides a single, simplified interface.

Proxy: Provides a surrogate or placeholder for another object to control access to it. Proxy object acts as an intermediary between the client and the target object. The proxy object has the same interface as the target object. The proxy object holds reference to the target object. There are different types of proxies:

Remote Proxy: provides a reference to an object, which resides in a separate address space. e.g. EJB, RMI, CORBA etc (RMI stubs acts as a proxy for the skeleton objects.)

Virtual Proxy: Allows the creation of memory intensive objects on demand. The target object will not be created until it is really needed.

Access Proxy: Provides different clients with different access rights to the target object.


On the side note:

Many patterns are structurally similar, if not identical. What you need to understand is where, how, and when to use it. For example:

Decorator pattern looks similar to the Proxy pattern. The Proxy pattern sets the relationship between a proxy and the real subject at compile time, whereas the decorators can be recursively constructed at runtime.


Proxy pattern is generally applicable to the client tier and facade is applicable to the business tier. E.g. Session facade.

Facade hides who you are talking to whereas proxy hides the location of the callee. E.g. EJB, RMI

[Ilja Preuss]

The most obvious difference is that a Proxy has *the same interface* as the original object. That is, clients don't even need to know whether they are acting on a proxy or directly on the real thing.

The intent of the Facade, in contrast, is to *change* the interface - generally to make it more coarse grained.

With other words, switching clients from using the original objects to using a Proxy typically needs no work at all. Switching them to using a Facade typically should significantly change the clients - that is, simplify them.