Object Interaction Patterns: Facade

Published: 2020-11-06 02:45:40

## What are object interaction patterns?
Object interaction patterns define how a set of objects interact and falls typically under 3 categories: creational patterns, structural patterns and behavioural patterns. These patterns are described below:

**Creational patterns** provide ways to instantiate single objects or groups of related objects
**Structural patterns** provide a manner to define relationships between classes or objects
**Behavioural patterns** define manners of communication between classes and objects

## What is a Facade?
Facade pattern falls under the structural category, providing a simple and specific interface onto a group of complex objects. Similar to a facade in architecture, which is the outward facing appearance of a building, a facade serves as a front-facing interface, hiding the complex underlying code away from the client. The participants of the Facade pattern are as follows:

**Facade** delegates the client request to appropriate subsystem classes, allows only one way communication from facade to subsystem
**Subsystems** implement subsystem functionalities, does not know of facade
**Client** requests facade to perform an action

### Benefits
Now, adding a facade interface means the client can use the facade to request for a certain action without directly calling the subsystem objects. This reduces complexity for client interaction as calls to the underlying code can be concentrated at one single point.

Having a facade also improves readability and usability, consolidating all the services as a single interface to make it more understandable. Creating facades also can allow you to define entry points to different levels of a subsystem. This also allows you to have loose coupling between subsystems by requiring them to only communicate through facades. 

As such, facades can be very helpful in simplifying large complex systems where there are multiple subsystems tightly coupled to each other, which makes it hard for the developer to maintain the codebase and for future developers to read and understand the structure of the system as well. 

### Drawbacks
However, there can also be some drawbacks of the facade patten. By creating extra interfaces, more code is required to be maintained leading to a larger codebase. 
This may not be so efficient for smaller projects as the increase in workload creating facades may outweigh the benefits mentioned in the previous section.

### Real life example
An example where the facade pattern could be used is in the Key Word in Context (KWIC) problem system. The KWIC index system accepts an ordered set of lines, where each line is an ordered set of words and each word is an ordered set of characters. KWIC outputs a list of all circular shifts of all given lines in alphabetical order, where circular shifting is done by repeatedly removing the first word and appending it at the end of the line. 

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/wao1l6zu3mrph51u4x6t.png)

There are two main subsystems in the KWIC index system, namely the circular shift, which circular shifts each line, and alphabetizer, which arranges the final output in alphabetical order. These two subsystems ultimately create the output that the client wants, but the client does not have to know how exactly the output is formed. Therefore, as seen in the diagram, a facade can be used to separate the logical implementation of KWIC. The client only needs to know of the facade and the facade subsequently calls the various subsystems to get the final result through unidirectional communication, as shown by the single headed arrow.