Search code examples
design-patternsumlfacade

Design Patterns - Understanding Facade Pattern

I'm new to Design Patterns and am trying to learn how they typically look like. Right now I'm trying to understand the Facade Pattern. I feel like the Facade Pattern is a rather broad concept, and so I was wondering if my second diagram would be considered a part of the Facade Template.

I know a typical Facade Pattern basically looks like this(with the A-class being the facade):

enter image description here

But what if we have a more subtle diagram like this:

enter image description here

Would the A-class still be considered a Facade-class or does it depend on the context?

Solution

  • First, to understand facade, I like to think of it as a kind of refactoring. Imagine both your diagrams without the facade classes. The clients would have to interact directly with all the classes that the facade manages. As such, they would be more complex, with more coupling.

    A facade provides a simplified service to the clients (reducing coupling), hiding the complexity behind the facade.

    My favorite example (in Java) is the JOptionPane class. It did not exist in the earliest versions of Java, and if you wanted to create a Yes/No question dialog, you (as a client) had to manage all the calls to Dialog, Button, etc. as well as handle the events, etc. All that complexity has been simplified into a static method inside the JOptionPane facade class. Here's a UML diagram from https://best-practice-software-engineering.ifs.tuwien.ac.at/patterns/facade.html

    enter image description here

    Now to your question:

    Would the A-class still be considered a Facade-class or does it depend on the context?

    If A is providing a simplified service to the clients that effectively uses the complex subsystem of B, C, F and E, without which the clients would have to interact with (be coupled to) all of them directly, then I'd say A is a facade.