A real life application is never implemented as a monolithic block. That is a sure way to disaster. The application should be divided into multiple subsystems that interact with each other according to a defined protocol. This makes things more manageable and extensible - so that a change in one component does not impact the others. If we can achieve such isolation, we can guess that we are on the right track.
Just having multiple subsystems is not enough. The subsystems should be separate in spirit - not just in code - else an isolation is impossible. If the subsystems are truly independent, then the implementation of one has no relation with that of the other - so long as they follow the agreed interface.
In object oriented design, such a protocol is often implemented in form of a façade class. The façade class receives method calls from the rest of the application and passes them to the appropriate code within the subsystem - that is isolated from the application.
There is an important point we must remember when working with a façade class. Ideally the façade class should just pass on requests to the appropriate code within the module. But, at times developers tend to use it as a "shock absorber" - that just absorbs any changes that are required. This bloats the façade class and then damages the design pattern - reducing the maintainability. The façade class should remain a façade and nothing more than that.
Provide a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use. For example, consider a compiler that has many components hidden behind a simple interface.
There are two participants in this pattern: