Facade Design Pattern

Facade is a structural design pattern that provides a simplified interface to a library, a framework, or any other complex set of classes.

Category

PlatformHub Integration

Scope - Problem

MobileX has build multiple libraries for different components and functionalities and they are tightly coupled with base application and journeys hence the code has dependency on third party libraries as well so here PlatformHub's requirement is to provide a simplified interface to sub-systems and abstract the complexity.

Scope - Pattern Context

A facade pattern, It hides the complexities of the system and provides simplified interface to the client from where the client can access the system without knowing the data sources too.

When to Use This Pattern

We can use Facade pattern for below cases.

• You have a complex system that you want to expose to clients in a simplified way.
• You want to structure a subsystem into layers.
• You want your code isolation, abstraction and reduce the complexity.
• You want to reduce object hierarchy while accessing the object.

Design and Implementation

High Level View

Let's check this bank transaction example. Each transaction involves subsystems like customer details, payment details and account details. It also involves other Facade systems. Each object is linked to other objects directly or indirectly. Traditionally, if we try to access the transaction details it's very difficult to access each object and check its relationship with other objects, also the client needs to know the whole system to get that transaction information. Here we have created a transaction details class that will act as an abstract Facade layer. It holds object references of other sub systems and other Facade systems (i.e. account and facilitate all information in one place, this is many to one relation). Thats how we can abstract multiple subsystems and another Facade systems under this layer.

Another examples in MobileX are domain models. They are just an objects containing the data relevant to domain.

In PlatformHub we have to access these domain models with the help of "Domain Model Plugin".

1. Customer Profile
2. Account (Domestic, Global)
3. Product Shelf
4. Transaction History

Reference Class Structure

This implementation uses the object composition principle: Single interface will facilitate all functionalities from related subsystems to access the system.

Code

Access-Facade

public class Client
{
    fun main(args: Array<String>) {
 
        val transaction: Transaction = Transaction()
        val customer : CustomerDetails = transaction.getCustomerDetails()
        val paymentDetails : PaymentDetails = transaction.getPaymentDetails()
        val accountDetails: AccountDetails = transaction.getAccountsDetail()
    }
}

Transaction - Facade

public class Transaction
{
    public fun getCustomerDetails() : CustomerDetails{
        val customerDetails = CustomerDetails()
        return customerDetails
    }
       
    public fun getPaymentDetails() : PaymentDetails{
        val paymentDetails = PaymentDetails()
        return paymentDetails;
    }
       
    public fun getAccountsDetail() : AccountDetails{
        val accountDetails = AccountDetails()
        return accountDetails
    }   
}

Sub Systems

class CustomerDetails{ /*...*/ }
 
class PaymentDetails { /*...*/ }
 
class AccountDetails { /*...*/ }
 
class SavingAccount  { /*...*/ }
 
class CurrentAccount { /*...*/ }

Issues and Considerations

• Complex implementation (especially with existing code)
• A facade could become a god object coupled to all classes of an app.
• High degree of dependence at facade interface.
• It will increase the object hierarchy, benefit is no need to understand whole system.
• Good to have functions for single functionality.

Forces and Constraints

• As its single communication layer so it could occupy have high memory so avoid multiple Facade layers.
• Avoid business logic implementation in this layer keeps it simple.
• Always measure cyclomatic complexity of this layer.

Read More Patterns