How to implement the Facade Design pattern in Java

Photo by Caspar Camille Rubin on Unsplash

Facade is one of the design pattern we usually use throughout the projects we work on, but we fail to tell and recognize it as we don’t even know that what we have implemented as developers for a given problem is a facade pattern.

How can I describe a facade design pattern? Just by use of an example, assume, literally even without assuming we consume third party APIs for most of the functionalities that we support in applications we build.

In our case let us assume we are consuming a file uploading API that has over 20 functionalities that you can access/ consume differently, and for our specific use case, we have to work with 4 resources in order to have our file uploaded successfully.

In the four resources from the third-party api, we have to:-

1. Authenticate/ check authorities of the user
2. Process the file
3. Upload the file
4. Get the metadata if the upload was successful
5. Lastly return the result of the upload

In the above code representation, what we have done is to get all the methods that we need to work with to successfully upload a file and consolidate/ group them together in a single method. With this approach, the class that is concerned with uploading files, will:-

1. Call a single method, provide the apiKey and file to be upload and then wait for the response.
2. Not concern itself with implementation details from the third-party API upload file method.
3. Not know that we are using a third party api to upload the file or even the number of methods and processes for the upload to happen.
4. In the event that the third-party api changes, the only change required is a single point in code and the rest of the application will continue to work.
5. Also in the event of switching from one api provider to another or to an internally developed system, a single point is changed in our entire code.

In the above example as we mentioned that our fictitious API has 20 methods, the above implementation puts the developer at ease not to worry about the methods exposed and what to use on not to use.

The facade pattern can as well be used when consuming more than one api to perform a functionality, let us say:-

api A, you need to consume method1() and method3()

api B, you need to consume methodC() and methodZ()

you can write a facade that calls

facade(){

method1();

method3();

methodC();

methodZ();

}

With this done, the developer is only concerned with invoking the facade method and will not care about the nitty-gritty of what is happening with the two APIs A and B.

In cases where you working with incompatible data from the third-party in your application. You can use a facade to transform this data from the third-party API to the data that your application supports (from XML to JSON) and it is the JSON data that you return to whoever is invoking the facade method. The possibilities are endless but we have to dive into an example that I prepared of two fictitious fintech APIs that support crediting, debiting and checking account balance of users.

1. Since our case if a fictitious scenario, we shall have an interface Payment that both fintechs will have to implement.

Payment interface

2. Secondly we see these two fintechs implement the Payment interface in their own ways.

The MmPay implements the Payment interface and it’s methods in it’s own way.

The same goes for AtPay, it implements the methods in its own way.

4. Given that we want to consume these API and we don’t want the developer to struggle with the API documentation consisting of the API methods to call to display the balance, credit or debit an account, we use the facade and the developer only calls the methods of the facade and the rest will take care of itself.

1. In the above code, first we create two variable of type AtPay and MmPay respectively and we make them private as we dont want the consumer of our facade to access or modify them
2. Inside the MyFacade constructor, we create both instances of the AtPay and MmPay classes
3. Now we create specific methods that are accessible outside of this facade class and inside the methods we invoke/ call the required methods from both the AtPay and MmPay APIs to perform the required tasks. That is all that is there to a facade.

5. And lastly the developer consumes the facade methods.

In the above snippet, you can see that we just created a single instance of the MyFacade class, and we can call all the methods on it, either for AtPay or MmPay. At this level we don’t care about the inner working of those APIs.

Here is the full code of what has been discussed, hope you learnt something valuable and can start using the facade design pattern where applicable.

Apologies, I failed to organize it in order of how it is used in the program but hope one can follow along.

Facade Design pattern

Some of the resources I worked with.

Facade

Design Patterns - Facade Pattern