Difference between Facade, Front Controller and command pattern

Dear All,

I do not really possess deep understanding of many mystical design patterns and terms used in them. I have googled also without too much of layman help. I was wondering if someone could spare time and be kind enough to let me know the difference between front controller, facade (Session Facade : is in terms of EJBs I guess, am I correct ?) and command pattern.
From my current undestanding the essential difference between em is

facade
Gives a single entry point for objects and I suppose base on a lot of if else's fetches the right implementation. All in all : simplifies the access process.
front controller : Is again a single entry point for accessing other complex lines of code. All in all: simplifies the access process.
command pattern : Based on the case the specific objects are called. All in all: simplifies the access process.

Kindly help the confused mind

rgds
[ October 17, 2007: Message edited by: Mike Anna ]

First of all: Session Facade is not a Facade. Session Facade is the name for a J2EE pattern where you apply a remote interface to a bunch of Transaction Scripts (which are usually considered part of the Session Facade).

A Facade in the general sense does not contain any business logic - the Session Facade often does.

A Facade is placed in front of a bunch POJOs; the business logic is contained in the POJOs and they are not part of the Facade.

When you push your business logic into an Application Service (instead of keeping it as a bunch of transaction scripts), the Session Facade starts to resemble a Remote Facade.

Article: Understanding The Facade Pattern

There is also sometimes confusion between a Session Facade and a Business Delegate. Have a look at this.

A client of a Facade decides with of the many methods to call. The front controller isn't in direct contact with the client. The front controller receives a request that originated from the client. The front controller inspects that request and the Front controller decides what code to call (as opposed to the client). Then it returns the resulting response.

PoEAA: Front Controller
Core J2EE Patterns 2e: Front Controller
Core J2EE Patterns: Front Controller
Blueprints: Front Controller

Compare the Facade Consequences to the Command Consequences (GoF):
Facade

It shields clients from subsystem components, thereby reducing the number of objects that clients deal with and making the subsystem easier to use.

It promotes weak coupling between the subsystem and its clients. Often the components in a subsystem are strongly coupled. Weak coupling lets you vary the components of the subsystem without affecting its clients. Facades help layer a system and the dependencies between objects. They can eliminate complex or circular dependencies. This can be an important consequence when the client and the subsystem are implemented independently.

Reducing compilation dependencies is vital in large software systems. You want to save time by minimizing recompilation when subsystem classes change. Reducing compilation dependencies with facades can limit the recompilation needed for a small change in an important subsystem. A facade can also simplify porting systems to other platforms, because it's less likely that building one subsystem requires building all others.

It doesn't prevent applications from using subsystem classes if they need to. Thus you can choose between ease of use and generality.

Command

Command decouples the object that invokes the operation from the one that knows how to perform it.

Commands are first-class objects. They can be manipulated and extended like any other object. (With facades you simply use the methods of the facade).

You can assemble commands into a composite command.

It's easy to add new Commands, because you don't have to change existing classes. (To add a method to a facade you have to change existing classes)

Both patterns enhance decoupling/weak coupling - otherwise they aren't related. The Facade pattern is a structural pattern, while the Command pattern is a behavioral pattern.

Command Pattern
Facade Pattern

A couple minor nits ...

A Facade might contain "business logic." While it's not usually the driver for having a Facade, even Shalloway's article talks about using one to add functionality. Depending on today's definition of "business," simply orchestrating a sequence of low level calls might qualify.

A Facade (or class visibility) might "prevent applications from using subsystem classes" if the implementer wants the freedom to add, change or remove subsystem classes over time. I worked on one system where one Facade per module/team made the only public APIs and it worked out to great effect.

Session Facade was an unfortunate term and definition. I have used Session Beans that were Facades, but not Session Facades. Enough to make your head hurt for sure.

Great. Thanks a ton for your replies. I will give some time for this to sink in, though :roll:

Rgds
[ October 18, 2007: Message edited by: Mike Anna ]

A facade is exactly what it means in the english language...something that acts as a front to other things. It is not a single point of access in the frontcontroller sense. For example a facade may expose 1 business API that may aggregate 3 separate business APIs...so instead of calling 3 separate methods you call only 1 making the API simpler to use.

A frontcontroller manages delegation, it recieves a request and then decides which module should handle that request.