Editing Facade pattern

{{Short description|Software design pattern}}
The '''facade pattern''' (also spelled ''façade'') is a [[software design pattern]] commonly used in [[object-oriented programming]]. Analogous to a [[façade]] in architecture, it is an [[Object (computer science)|object]] that serves as a front-facing interface masking more complex underlying or structural code. A facade can:
* improve the readability and usability of a [[software library]] by masking interaction with more complex components behind a single (and often simplified) [[application programming interface]] (API)
* provide a context-specific interface to more generic functionality (complete with context-specific input [[Data validation|validation]])
* serve as a launching point for a broader [[Code refactoring|refactor]] of [[Monolithic system|monolithic]] or tightly-coupled systems in favor of more [[Loose coupling|loosely-coupled]] code

Developers often use the facade design pattern when a system is very complex or difficult to understand because the system has many interdependent classes or because its source code is unavailable. This pattern hides the complexities of the larger system and provides a simpler interface to the client. It typically involves a single [[wrapper class]] that contains a set of members required by the client. These members access the system on behalf of the facade client and hide the implementation details.

==Overview== 
The Facade
<ref name="GoF">{{cite book|author=Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides|title=Design Patterns: Elements of Reusable Object-Oriented Software|year=1994|publisher=Addison Wesley|isbn=0-201-63361-2|pages=[https://archive.org/details/designpatternsel00gamm/page/185 185ff]|url-access=registration|url=https://archive.org/details/designpatternsel00gamm/page/185}}</ref>
design pattern is one of the twenty-three well-known 
''[[Design Patterns|GoF design patterns]]'' 
that describe how to solve recurring design problems to design flexible and reusable object-oriented software, that is, objects that are easier to implement, change, test, and reuse.

What problems can the Facade design pattern solve?
<ref>{{cite web|title=The Facade design pattern - Problem, Solution, and Applicability|url=http://w3sdesign.com/?gr=s05&ugr=proble|website=w3sDesign.com|access-date=2017-08-12}}</ref>

* To make a complex subsystem easier to use, a simple interface should be provided for a set of interfaces in the subsystem.
* The dependencies on a subsystem should be minimized.

Clients that access a complex subsystem directly refer to (depend on) many different objects having different interfaces (tight coupling), which makes the clients hard to implement, change, test, and reuse.

What solution does the Facade design pattern describe?

Define a <code>Facade</code> object that 
* implements a simple interface in terms of (by delegating to) the interfaces in the subsystem and
* may perform additional functionality before/after forwarding a request.

This enables to work through a <code>Facade</code> object to minimize the dependencies on a subsystem.
<br>
See also the UML class and sequence diagram below.

== Usage ==
A Facade is used when an easier or simpler interface to an underlying object is desired.<ref>{{cite book | last1 = Freeman | first1 = Eric | last2 = Freeman | first2 = Elisabeth | last3 = Sierra | first3 = Kathy | last4 = Bates | first4 = Bert | editor1-last = Hendrickson | editor1-first = Mike | editor2-last = Loukides | editor2-first = Mike | year = 2004 | title = Head First Design Patterns | volume = 1 | pages = 243, 252, 258, 260 | publisher = O'Reilly | format = paperback | isbn = 978-0-596-00712-6 | access-date = 2012-07-02 | url = https://www.goodreads.com/book/show/58128.Head_First_Design_Patterns
}}</ref> Alternatively, an [[Adapter pattern|adapter]] can be used when the wrapper must respect a particular interface and must support [[Polymorphism (computer science)|polymorphic]] behavior. A [[Decorator pattern|decorator]] makes it possible to add or alter behavior of an interface at run-time.
{| class="wikitable"
! Pattern !! Intent
|-
| [[Adapter_pattern|Adapter]] || Converts one interface to another so that it matches what the client is expecting
|-
| [[Decorator_pattern|Decorator]] || Dynamically adds responsibility to the interface by wrapping the original code
|-
| Facade || Provides a simplified interface
|}

The facade pattern is typically used when
* a simple interface is required to access a complex system,
* a system is very complex or difficult to understand,
* an entry point is needed to each level of layered software, or
* the abstractions and implementations of a subsystem are tightly coupled.

==Structure==
=== UML class and sequence diagram ===
{{multiple image
| direction=horizontal
| footer=A sample UML class and sequence diagram for the facade design pattern
| image1=Facade Design Pattern Class Diagram UML.svg
| alt1=Facade Design Pattern Class Diagram
| width1=300
| image2=Facade Design Pattern Sequence Diagram UML.svg
| alt2=Facade Design Pattern Sequence Diagram
| width2=350
}}
In this [[Unified Modeling Language|UML]] [[class diagram]], 
the <code>Client</code> class doesn't access the subsystem classes directly.
Instead, the <code>Client</code> works through a <code>Facade</code> class that implements a simple interface in terms of (by delegating to) the subsystem classes (<code>Class1</code>, <code>Class2</code>, and <code>Class3</code>).
The <code>Client</code> depends only on the simple <code>Facade</code> interface
and is independent of the complex subsystem.<ref>{{cite web|title=The Facade design pattern - Structure and Collaboration|url=http://w3sdesign.com/?gr=s05&ugr=struct|website=w3sDesign.com|access-date=2017-08-12}}</ref>

The sequence diagram 
shows the run-time interactions: The <code>Client</code> object 
works through a <code>Facade</code> object that delegates the request to
the  <code>Class1</code>, <code>Class2</code>, and <code>Class3</code>
instances that perform the request.

=== UML class diagram ===
[[File:Example of Facade design pattern in UML.png]]
; Facade
: The facade class abstracts Packages 1, 2, and 3 from the rest of the application.
; Clients
: The objects are using the facade pattern to access resources from the packages.

== Example ==
<!-- Wikipedia is not a list of examples. Do not add examples from your favorite programming language here; this page exists to explain the design pattern, not to show how it interacts with subtleties of every language under the sun. Feel free to add examples here: http://en.wikibooks.org/wiki/Computer_Science_Design_Patterns/Facade -->
<!-- In this example the author has confused a facade with a class composed of other components that it uses. This should be rewritten. -->

This is an abstract example of how a client ("you") interacts with a facade (the "computer") to a complex system (internal computer parts, like CPU and HardDrive).

=== C++ ===
<syntaxhighlight lang="c++">
struct CPU {
  void Freeze();
  void Jump(long position);
  void Execute();
};

struct HardDrive {
  char* Read(long lba, int size);
};

struct Memory {
  void Load(long position, char* data);
};

class ComputerFacade {
 public:
  void Start() {
    cpu_.Freeze();
    memory_.Load(kBootAddress, hard_drive_.Read(kBootSector, kSectorSize));
    cpu_.Jump(kBootAddress);
    cpu_.Execute();
  }

 private:
  CPU cpu_;
  Memory memory_;
  HardDrive hard_drive_;
};

int main() {
  ComputerFacade computer;
  computer.Start();
}
</syntaxhighlight>

== See also ==
* [[Encapsulation (computer programming)]]

==References==
{{Reflist}}

==External links==
{{wikibooks|Computer Science Design Patterns|Facade|Facade implementations in various languages}}
{{Commons category|Facade pattern}}
* [http://c2.com/cgi/wiki?FacadePattern Description from the Portland Pattern Repository]


{{Design Patterns Patterns}}

<!--Categories-->
[[Category:Software design patterns]]
[[Category:Articles with example C Sharp code]]
[[Category:Articles with example Java code]]
[[Category:Articles with example Ruby code]]