Facade Pattern

*Disclaimer these writings are for my own learning purposes not as advice to others. If any part is incorrect please feel free to constructively discuss.

Previously I discussed
Strategy Pattern
Factory Pattern
Abstract Factory Pattern
Observer Pattern

The Facade pattern is widely used, and frameworks, and API's  are common implementers of this pattern. Often times a complex API or framework can have interfaces capable of large amounts of functionality and complexity. There may be too much complexity for the intended client to have to deal with. Stringing together a series of function calls for example. This is where the Facade pattern comes in to play. The Facade simply provides a layer of abstraction and or encapsulation by wrapping one or more complex interfaces to provide a unified interface showing only what is necessary to the intended client.

Considerations when implementing a facade layer:
Necessity: Is the facade really unifying complex interfaces for a client that doesn't need to use or understand all the functionality.
Forcing: Is the facade forced on the client? A facade should be bypass-able.
Adding functionality: Is the facade adding functionality? It shouldn't. Its primary focus is to unify a subsystem. It may collect some information to call several methods within the subsystem, therefore unifying functionality, but if functionality is added it might not really be the facade pattern, maybe Decorator instead.

Drawing from the automotive realm again Lets take the ignition process as an example. You the client want to turn the key and have the car start. You don't want to to think about the ignition switch allowing the electrical system to have power from the battery and in turn send electricity to the starter solenoid. The solenoid to send power from the battery to the starting motor. The gear on the starting motor to turn the larger gear on the flywheel. The flywheel to turn the crank driving the pistons. The vacuum from the pistons to pull atomized fuel and air mixture from the carburetor into the cylinders to be ignited by the spark plugs firing inside the cylinders... You just want your start method. You want to call it and let the rest of the stuff behind the scenes happen without your knowledge.

*Note it may be tempting to implement your facade as a singleton. Take a look at this interesting article discussing singleton, GoF patterns, their association with C++, and when is the best time to use a singleton. Its an interesting read. I'm not saying you shouldn't use it but just something of interest.

Here is that ignition example in code. (*Not how I would layout an object model for a serious project relating to an engines ignition process. But, its complex enough to get the point across for this demo).
The entire solution containing this project and the previously discussed projects can be found here.

//Ignition class


//Starter class and solenoid interface. Implements ISolenoidElectronic indicating it is a type of device that //requires a solenoid and should be expected to have a run method. (Not necessary for the Facade pattern //just makes this example make more sense to me.


//Flywheel Class


//Crank


//Carburetor


//Cylinder


//Sparkplug


//Facade class