Facade Pattern

Intent: 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. This can be used to simplify a number of complicated object interactions into a single interface.

Extensions:

FacadesAsDistributedComponents - on how to use this pattern in a distributed system to expose more "coarse-grained" objects, improving performance and simplifying the cross

Facade is not actually a container, is it? It often seems to be diagrammed with a box around the objects to which it is providing a facade, but if it were a container this would mean that no other facades could be provided to the same set of objects (because of encapsulation). However, if it does not contain these objects then the facade's constructor must reference all the (pre-existing) objects, whereas if it contained them it could construct them itself. Either case adds a differing kind of complexity. What is the right way to do this? HughSasse? (The answer is to use the inversion of control pattern and have a Inversion of Control (IoC) Container or Lightweight Container to inject the dependencies to the facade driven by configuration. In this manner the facade is given pre-existing objects. The light weight container simply has to resolve the dependencies. Examples of such containers in Java would be NanoContainer?, Spring or ApacheHiveMind?.)

Facades are often implemented with containers, but the pattern is a specific sort of containership. Most containers don't expose the interfaces of contained objects to the world; they make use of those interfaces in their own way. Facade, on the other hand, exposes the interface of contained objects to the world, and the point of it is that this way clients don't have to be concerned with exactly which object in a subsystem they're dealing with. They just call their methods on the facade in blissful ignorance.

http://www.csc.calpoly.edu/~dbutler/tutorials/winter96/patterns/tutorial.html ( DeadLink )

http://wiki.cs.uiuc.edu/patternStories/FacadePattern ( DeadLink )

http://delphipatterns.blog.com/2011/03/21/facade

A facade is a semantic wrapper of existing objects, an extended form of the AdapterPattern. So you make your objects and attach the facade. The binding can occur at any time you like, not just at facade construction time. -- RichardHenderson.

So the facade could even look to see if the objects it wraps exist currently and bind if they do, or indeed, the objects could request that the facade be created, so the responsibility is "on the other foot" so to speak? (I think I'm still not used to making things quite so dynamic!) HughSasse?

A facade can in-fact consist of more than a single class. Consider a file-system object model, where classes exist that represent files, directories, allocation mechanisms, etc. At the implementation level, these classes may have high-coupling interactions which may require exposing some gory-detail members -- which one might want to hide from clients of the object model. Languages such as Eiffel have a fine-grained access-control mechanism, allowing different clients to effectively see different interfaces of the same object -- this achieving this goal. Java partially solves things with package access. Other languages, however, such as C++, don't offer such functionality in a tasteful manner (friend classes bad for you). In these languages, creating a facade object-model (that is an object model parallel to the filesystem object model, with a 'simpler' interface) allows supplying different interfaces to different clients while maintaining the core functionality common.

If someone has good abstraction and provide a good facade at every object, then I believe that NothingIsComplex?. -- JokoIlang --- What would be the scenarios where the facade be an extended form of the AdapterPattern? -- Kalyan

Kalyan, I'm writing a piece of software called Nemo that bridges acts as a FacadePattern for a client program around a database-like API. Working with different databases is often complicated, so it provides an alternative API that can be used. However, Nemo also acts as an AdapterPattern, since it adapts the database's API to one that the client expects (the easy-to-use API). -- JimmyCerra

Java interfaces provide a useful abstraction capability. One can have a class Foo implement some interfaces, say A, B, and C. Some client code may get a reference of type A, others one of type B, etc. each actually the same Foo object but the interface exposing only a narrow subset of the functionality. Of course, evil client code can try to cast the A reference to Foo, then access the other functionality, but then encapsulation only works well when the programmers cooperate anyway, right? This gives fine-grained access control of a sort, showing different interfaces or aspects of the Foo to different code. Foo basically has three faces.

Well, instead of giving client code a reference to a Foo instance dressed as an A, you could give them a proxy; an object which implements A and delegates all method calls to your Foo instance. This would avoid typecast hacks.

As per my understanding, Session Facade is to simplify use of Services,i.e.

1) Coarse Grained access of services available - If i have a service class and i want to access methods available in it, i have to use Session Facade to call those methods.

2) Hides complex implementation - How internal implementation is, used wont be aware of it.

3) Reduces network calls - It takes remote calls once for a methos of facade, and facade makes required calls to other methods locally and returns result.

4) Wrapper around service - If your service class is a plain java class, then using Stateless Session Bean will awail you benefits of EJB container, transaction, security, persistance etc.

Refer : http://www.corej2eepatterns.com

mailto:abhishek.shahi@gmail.com