Factory v/s Facade Design Pattern.

The Factory Pattern :

--------------------------------------------------------------------------------
The factory completely abstracts the creation and initialization of the product from the client
This indirection enables the client to focus on its discrete role in the application without concerning itself with the details of how the product is created. Thus, as the product implementation changes over time, the client remains unchanged.

Client--------------------->Factory----------------->Product


The Facade Pattern



--------------------------------------------------------------------------------
Encapsulate the subsystem using a High-Level Interface/provides a
simplified and uniform interface to a large subsytem of classes.

The Client communicates with the 'Facade' which has methods to interact
with subsystems.The Client very rarely accesses objects in the subsystems.
Subsystems objects usually retain no knowledge of the client.
Subsystem objects do not normally maintain any reference to Faýade.

Client------------------->Facade------->Subsystems


My Question is this:

Arent both these pattern quite similar becos both designs access an Interface
which inturn invokes the required object of the subsystems?

Can anyone explain the major difference?

1. the Factory Pattern, is very useful for the creation of
the objects which it then hands to you and you deal with
the objects directly.

The Facade pattern, tries to simplify things for you, as
it keeps the objects away from you. This simplifies your
life if you are dealing with several complex objects.

2.Faýade
The Faýade pattern simplifies access to a related set of objects by providing one object that all objects outside the set use to communicate
with the set. This also promotes a weak coupling between the subsystem and its clients. This weak coupling allows you to vary the
components of the subsystem without affecting the clients.

Factory
Centralize the assembly of resources necessary to create an object. This prevents the need to change all classes from changing when a
Product changes and makes any change needed occur only in the Factory.

Structural Patterns - Facade Pattern

Overview
This article provides a brief introduction to Facade Design Patterns. Facade Design pattern provides an easy to use interface to an otherwise complicated collection of interfaces or subsystems. It makes things easier by hiding the details of the implementation.

When designing good programs, programmers usually attempt to avoid excess coupling between module/classes. Using this pattern helps to simplify much of the interfacing that makes large amounts of coupling complex to use and difficult to understand.

In a nutshell, this is accomplished by creating a small collection of classes that have a single class (Facade) that is used to access them.

The facade pattern is an object-oriented design pattern. A facade is an object that provides a simplified interface to a larger body of code, such as a class library. A facade can accomplish all of the following.

It can make a software library easier to use and understand since the facade has convenient methods for common tasks.
It makes code that uses the library more readable for the same reason.
It can reduce dependencies of outside code on the inner workings of a library since most code uses the facade. This allows for more flexibility in developing the system.
It can wrap a poorly designed collection of APIs with a single well-designed API.
The following Non-software and software examples demonstrate this pattern.

Non-Software examples
In most of the Pizza centers, orders will be given through phone calls with the customer interacting with the Customer service representative. In this case, consumers do not have access to the Billing system, Kitchen and delivery department. The customer service representative acts as an interface and interacts with each of the departments involved in the transaction and ensures that Pizzas are delivered to the consumer.

We can relate this non-software example against the facade design pattern in the following way:

Customer Service representative corresponds to the facade.
Individual departments involved in the transaction correspond to Sub-systems.
Another example we can consider is Emergency services. In the event of fire we just inform an Emergency Service operator. The emergency operator interacts with police, ambulance and fire services and dispatches them. Here the client is shielded from individual emergency services.

Software examples
Web Service Facade Solution Architecture provides an example for Facade design pattern. In this architectural solution, instead of rewriting legacy applications or customizing those with middleware to connect to other applications one by one, this solution helps create a "facade" for the legacy application. Other applications are easily "plugged into" this facade. By modeling a legacy application into its basic functions of create, read, update, and delete and then exposing these functions as Web methods, the Web service facade solution allows other applications to access legacy data by making use of common Web services through standardized protocols. In this way, Facade decouples layers so that they do not depend on each other which can make it easier to develop, to use and to promote code re-use.

Facade as the name suggests means the face of the building. The people walking past the road can only see this glass face of the building. They do not know anything about it, the wiring, the pipes and other complexities. The face hides all the complexities of the building and displays a friendly face.

This is how facade pattern is used. It hides the complexities of the system and provides an interface to the client from where the client can access the system. In Java, the interface JDBC can be called a facade. We as users or clients create connection using the “java.sql.Connection” interface, the implementation of which we are not concerned about. The implementation is left to the vendor of driver.

Definition
Make a complex system simpler by providing a unified or general interface, which is a higher layer to these subsystems.

Where to use & benefits
Want to reduce complexities of a system.
Decouple subsystems , reduce its dependency, and improve portability.
Make an entry point to your subsystems.
Minimize the communication and dependency between subsystems.
Security and performance consideration.
Shield clients from subsystem components.
Simplify generosity to specification.

Related patterns include
Abstract Factory, which is often used to create an interface for a subsystem in an independent way, and can be used as an alternative way to a facade.
Singleton, which is often used with a facade.
Mediator, which is similar to facade, but a facade doesn't define new functionality to the subsystem.

Example
JDBC design is a good example of Façade pattern. A database design is complicated. JDBC is used to connect the database and manipulate data without exposing details to the clients.

Security of a system may be designed with Façade pattern. Clients' authorization to access information may be classified. General users may be allowed to access general information; special guests may be allowed to access more information; administrators and executives may be allowed to access the most important information. These subsystems may be generalized by one interface. The identified users may be directed to the related subsystems.

interface General {
public void accessGeneral();
}
interface Special extends General {
public void accessSpecial();
}
interface Private extends General {
public void accessPrivate();
}

class GeneralInfo implements General {
public void accessGeneral() {
//...
}
//...
}
class SpecialInfo implements Special{
public void accessSpecial() {
//...
}
public void accessGeneral() {}
//...
}
class PrivateInfo implements Private, Special {
public void accessPrivate() {
// ...
}
public void accessSpecial() {
//...
}
public void accessGeneral() {
// ...
}
//...
}

class Connection {
//...

if (user is unauthorized) throw new Exception();
if (user is general) return new GeneralInfo();
if (user is special) return new SpecialInfo();
if (user is executive) return new PrivateInfo();
//...
}

The above code example illustrates that the whole system is not exposed to the clients. It depends on the user classification.