Design Pattern - Facade

Question

The Facade design pattern is centered around "Association" over inheritance, correct?

If there is a car system like this:

Car (class)

-> Body (class)

-> Steer wheel (class)

-> Chassie (class)

-> Wheels (class)

Then these classes are not inherited from Car are they? Because in theory, I've been taught that inheritance has a "Can be" relationship.. "Person CAN BE a Student" ... "Car HAS A Chassie" Which would infer that it is Association?

Any ideas? :)

Answer 1

I agree with the sentiment that whether the objects underneath are associated or inherit is an implementation detail which doesn't have much to do with how the pattern functions.

Frankly, Facade is a pattern that attempts to accomplish the same thing that componentization does: you cannot always make it easy to manipulate a bunch of different things, but you need one interface. The most common example you see all the time of Facade being applied in the Java world is to provide a means of using the JavaMail interface. You don't want to even have to deal with Sessions. It's stupid. Likewise, Spring's persistence classes are a facade, though they allow you to ignore sessions by using Aspects, and they also introduce perils of simplification, in that the session is actually different in successive invocations, hence OpenSessionInView.

The key question to ask in wondering whether Facade applies is what are you going to be able to hide? And will you really be able to accomplish it?

Answer 2

I would NOT agree with you, facade is not centered around association neither inheritance.

A facade is an object that provides a simplified interface to a larger body of code

meaning that it is used to provide higher-level view of subsystems and hide its complexity, whatever was the implementation of the subsystems is based on, association or inheritance.

another alternative to facade is transparent facade which let the client being able to go through it, and get access to individual operations of the sub systems.

the car system you are asking about is just an example, the pattern is not limited to it.

Answer 3

I would agree with you. The idea of the facade pattern is that you have bunch of associated objects that you wrap in a facade to make managing and manipulating those objects easier.

As Waleed Khan said in the comments, this example kind of blurs the line with composition because car is made of the different parts. We may have a case where the objects that make up the facade all work together without directly being the pieces of some larger entity.

The car example makes things easy because we can do things like car.turnLeft() which may affect both the wheels and the steering wheel. The coordination between the objects is handled by Car.

Answer 4

Yes. That is correct. Facade is centered around Association. It wraps a variety of related subsystems (which mostly work together) to provide a meaningful and simple interface to the client. The subsystems need not be in the same inheritance hierarchy but are almost always associated.

Your car example :

http://www.go4expert.com/forums/showthread.php?t=5127#facade

Answer 5

The Facade pattern is a variant of the Adapter pattern. The Adapter pattern "wraps" an interface and converts it to another (adapting it to the form in which a client expects it). Often used to adapt a new interface to older client software. Or to wrap old, crufty, Big-Ball-O-Mud software with a shiny new, presumably cleaner interface, with an eye towards replacing the old crufty code later.

The Facade pattern, on the other hand, wraps an interface, presenting a simplified form of it to the client.

Neither has much to do with composition versus inheritance.

You want look up the book Head First Design Patterns, by Eric Freeman and Elizabeth Freeman. Far better than the GO4 book, IMHO, as far as learning to do something with design patterns.