Design Patterns - Facade

Design Patterns - Facade

Facade pattern hides the complexities of the system and provides an interface to the client using which the client can access the system. Analogous to a facade in architecture, a facade is an object that serves as a front-facing interface masking more complex underlying or structural code.

This pattern involves a single class which provides simplified methods required by client and delegates calls to methods of existing system classes.


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.


Structuring a system into subsystems helps reduce complexity.

A common design goal is to minimize the communication and dependencies between subsystems.

One way to achieve this goal is to introduce a facade object that provides a single, simplified interface to the more general facilities of a subsystem.


For example a programming environment that gives applications access to its compiler subsystem.

This subsystem contains classes such as Scanner, Parser, ProgramNode, BytecodeStream, and ProgramNodeBuilder that implement the compiler.

Some specialized applications might need to access these classes directly.

Most clients of a compiler generally don't care about details like parsing and code generation; they merely want to compile some code.

For them, the powerful but low-level interfaces in the compiler subsystem only complicate their task.

To provide a higher-level interface that can shield clients from these classes, the compiler subsystem also includes a Compiler class. This class defines a unified interface to the compiler's functionality. The Compiler class acts as a facade.

It offers clients a single, simple interface to the compiler subsystem.

It glues together the classes that implement compiler functionality without hiding them completely.

The compiler facade makes life easier for most programmers without hiding the lower-level functionality from the few that need it.





  • knows which subsystem classes are responsible for a request
  • delegates client requests to appropriate subsystem objects

Subsystem classes

  • implement subsystem functionality
  • handle work assigned by the Facade object
  • have no knowledge of the facade; that is, they keep no references to it

Decorator forwards requests to its Component object. It may optionally perform additional operations before and after forwarding the request.


Use the Façade pattern when

  • you want to provide a simple interface to a complex subsystem. Subsystems often get more complex as they evolve. Most patterns, when applied, result in more and smaller classes. A facade can provide a simple default view of the subsystem that is good enough for most clients.

  • there are many dependencies between clients and the implementation classes of an abstraction. Introduce a facade to decouple the subsystem from clients and other subsystems, thereby promoting subsystem independence and portability.

  • you want to layer your subsystems. Use a facade to define an entry point to each subsystem level. If subsystems are dependent, then you can simplify the dependencies between them by making them communicate with each other solely through their facades.

Decorator forwards requests to its Component object. It may optionally perform additional operations before and after forwarding the request.


The Decorator pattern has at least two key benefits and two liabilities:

  1. More flexibility than static inheritance
  2. Avoids feature-laden classes high up in the hierarchy
  3. Decorator offers a pay-as-you-go approach to adding responsibilities.
  4. Instead of trying to support all foreseeable features in a complex, customizable class, - you can define a simple class and add functionality incrementally with Decorator objects
  5. A decorator and its component aren't identical.
  6. A decorator acts as a transparent enclosure. But from an object identity point of view, a decorated component is not identical to the component itself. Hence you shouldn't rely on object identity when you use decorators.
  7. Lots of little objects.
  8. A design that uses Decorator often results in systems composed of lots of little objects that all look alike.

Known Uses:

DebuggingGlyph prints out debugging information before and after it forwards a layout request to its component. This trace information can be used to analyze and debug the layout behavior of objects in a complex composition.

The PassivityWrapper can enable or disable user interactions with the component.

A stream can provide an interface for converting objects into a sequence of bytes or characters.

A stream can provide an interface for converting objects into a sequence of bytes or characters.

  • Compress the stream data using different compression algorithms
  • Reduce the stream data to 7-bit ASCII characters so that it can be transmitted over an ASCII communication channel.


Thank you for Reading.

Did you find this article valuable?

Support Balasundar by becoming a sponsor. Any amount is appreciated!