The Façade Pattern it is a very simple pattern, it seeks to simplify the system, from the point of view of the client, by providing a unified interface for a set of subsystems, defining a higher level interface. This makes the system easier to use. The GOF book says the Facade Pattern should “Provide a unified interface to a set of interfaces in a system. It defines a high level interface that makes the subsystem easier to use”.
This pattern seeks to minimize communication and dependencies between subsystems. For this, we will use a facade, simplifying the complexity to the client. The customer should access a subsystem through the Facade. In this way, a simpler programming environment is structured, at least from the client’s point of view (hence the name “façade”).
Facade: knows which subsystem classes are responsible for a request. Delegates customer requests to subsystem objects.
Subsystem: handle the work assigned by the Facade object. They have no knowledge of the Facade (they do not keep reference of this one).
Clients communicate with the subsystem through the facade, which forwards the requests to the appropriate subsystem objects and can also perform some translation work. Customers who use the facade do not need to directly access system objects.
When to apply it
- When the system has several identifiable subsystems
- The abstractions and implementations of a subsystem are tightly coupled
- There is an entry point needed for each layered software
Consider a system that play a song given a music file. Now the system needs to load, decoded and play the file. Our task is to write an application which will play the music file. Our application will have the following classes: MusicPlayerFacade, FileLoader, Decoder, Player
Music Player Facade
You can find the code of the example HERE
That’s all about the Façade Pattern. Thanks for reading.