Is "Facade design pattern" and Java interface conceptually same?

Question

Is "Facade design pattern" and Java interface conceptually same ? As both achieve abstraction by providing simple way of expressing a complex functionality. Can we say by creating interface we followed Facade pattern ?

Answer 1

No, I's not the same. For implementing Facade design pattern is not necessary to implement any interface. It just provide a new layer to communicate to your services, as an example.

class ServiceFacade() {
    private Service1 service1;
    private Service2 service2;

   public void update(Entity entity){
      service1.update(entity);
      service2.update(entity);
   }
}

So it will give you one point to communicate with all services that are related. Instead of calling service1.update() and service2.update() you just call facade.update(), so you are sure that both services update the entity.

One more example: maybe all the time service is updated you need to refresh() you cache. This also can be incapsulate in your Facade:

public void update(Entity entity) {
    service.update(entity);
    cache.refresh();
}

If your facade class has only one dependency, but you want to extend the functionality of this dependency, you can achieve that by implementing Decorator pattern. Here is where you do need to implement the interface. Let's take a look at the following example. Suppose you have a service and you want to extend it with a simple cache

class CachedService implement Service {
    private Service service;
    CachedService(Service service, Cache cache){
       ......
    }
    ......

    private Entity get(Long id) {
        Entity cachedEntity = cache.get(id);
        if (cachedEntity != null){
           return cachedEntity;
        }
        return service.get(id);
    }
}

Answer 2

Façade is a conceptual design pattern. There's no specific interface nor implementation.

It's just an additional layer on which you implement operations that otherwise would force upper layers to understand and be coupled to irrelevant implementation details for themselves.

For example, a façade method could be a credit card payment process on which you need to send many requests and process their responses to store the billing result on some database.

Without a façade method, every part of your system on which you need to perform a payment using a credit card would need to repeat those 5-10 code lines all over again. At some point, you find that you need an extra step when performing those operations and you realize that you need to refactor thousands of code lines. That is, your solution could have a security hole and you won't be able to respond to the security treat in time. A façade can make the difference from being a poor software provider to being a serious and robust one!

In the opposite side, when you implement proper façades, when some layer needs to perform a credit card payment it just injects a billing façade and it stays agnostic about how the billing process is being made hence you don't repeat yourself in many parts of your system and refactoring isn't a tedious and time-consuming task.

While façade pattern doesn't define an interface per se, façades should be defined as interfaces, since they can also act as proxies: an implementation could make use of the service layer directly and other might call a RESTful API to perform the same task, depending on who needs the façade itself.

Anyway, this design pattern isn't specific to simplifying a given service layer. You might consider a façade method a method that may simplify a complex string manipulation involving many regular expressions, replacements and insertions.

Answer 3

Facade hides the complexity of the system and provides an interface to the client from where the client can access the system, meaning that Facade hides low-level functionality from client.

Will that interface be java interface it is up to you.