Facade Design Pattern In Android

Image Credit Unsplash

Hello, fantastic and enthusiastic coder out there.

In Day-Today programming life you might have come across using multiple Libraries or multiple components at a single time at the project level and trying to make them work together. But some of us might have faced some problems while achieving abstraction which helps to reduce complexity. So to avoid complexity or complex logic we can use facade design patterns.

A facade design pattern is one of the Structural design patterns. Majorly this design pattern has the spotlight on rearranging the structure of objects more easily.

Let’s try to take a simple brief explanation of the Facade design pattern.

What is the Facade design pattern?

• Facade means a mask. which hides the complex implementation of any object of the client class.
• A facade is an object that provides a simplified interface to a more complex logic or functionality. This means it provides a higher level of the interface that makes a set of other interfaces easier to use.

What is the use case of the Facade design pattern?

• When there is a complex system that needs to get exposed to clients more easily.
• Decoupling application code from library code.
• Reusing legacy code in the new applications.

What are the advantages of Facade design patterns?

• This pattern avoids or keeps away the users from the complexities of the sub-system components.
• We can achieve loose coupling between subsystems and their users.

Code Snippet and Example

Let’s take a simple example of a Restaurant. The customer simply orders the food from the menu, and the customer doesn’t want to know who is going to take the order, who is going to cook, and who is going to wash the dishes. The customer simply wants to order the meal and eat. Therefore, the menu serves as a facade to make it easier for customers to avoid complexity coming from the kitchen or even from the waiter.

1. Now you have got an idea of what a facade does, it will provide simple interface logic to a complex subsystem. So let’s have two interfaces Waiter and Kitchen.

interface Waiter {     
     fun takeOrder()     
     fun sendOrderToKitchen()     
     fun serveFood() 
}
interface Kitchen {    
    fun prepareFood()      
    fun callWaiter()      
    fun washesDishes()  
}

2. Let’s create an implementation class for both interfaces.

class WaiterImpl : Waiter {    
     fun takeOrder() {       
         Logger.d("Taking order from customer")    
     }    
     fun sendOrderToKitchen() {      
         Logger.d("Sending order to kitchen")    
     }    
     fun serveFood() {       
         Logger.d("Serving food to customer")    
     }
}
class KitchenImpl : Kitchen {    
     fun prepareFood() {         
         Logger.d("Preparing food")     
     }     
     fun callWaiter() {         
         Logger.d("Calling waiter")     
     }
     fun washesDishes() {        
         Logger.d("Washing dishes")     
     }
}

3. And now we’re going to create one class as an OrderFood which will play the role of menu servers.

class OrderFood {
   val waiter: Waiter = WaiterImpl()  
   val kitchen: Kitchen  = KitchenImpl()  
 
   fun orderFood(oderId: String) {       
      waiter.takeOrder()     
      waiter.sendOrderToKitchen()       
      kitchen.prepareFood()       
      kitchen.callWaiter()       
      waiter.serveFood()       
      kitchen.washesDishes()   
   }  
}

4. Finally, Customer class, where the customer going to order the food.

class Customer {
   private val orderFood = OrderFood()     
   fun main() {       
     orderFood.orderFood("ORD123456789")
   } 
}

Takeaways

While developing an application we’re adding a few Third-Party Libraries which are having sets of classes in our project and provide some reusable code. The developer can directly add these classes from the library into the application after the library is included in the project.

But referencing directly to the library is not a good solution because application code is tightly coupled to the library and sometimes to a specific version of the library. And if the application has more dependency on this library then it’s more difficult while replacing the library with a newer version of the library. And that’s because the developer needs more careful while replacing usages of the old library with a new one.

So we can overcome this problem using a Facade design pattern. Using facade design pattern we can decouple application code From library code. The facade objects act like a wrapper over the library. And when a developer needs to replace an old version of the Library with a new one then the developer needs to focus only on changing the code inside the facade object only.

While using a facade pattern over a library code, it’s always good to restrict the direct reference or direct use of library code in the application. Fortunately, this is very easily achievable using the below steps

• By creating separate projects within the application and adding facade objects into it.
• Adding references from the project which has facades to the third-party library.
• Adding references from the application to the project by using facade only.

I hope you found this article informative and helpful. And Special thanks to Rohit Chandekar! for helping me to write this article.

Thank you 👏🏽