Java design patterns: Facade

Scenario

The server has exposed a complex interface to the clients which looks a bit hectic to them. We need to provide an easy way to start and stop the server.

A complex interface to the client is already considered as a fault in the design of the current system. But fortunately or unfortunately, we cannot start the designing and the coding from scratch. We need a way to resolve this problem and make the interface easy to access.

ScheduleServer is complex to start and stop

public class ScheduleServer {

public void startBooting() {
System.out.println("Starts booting...");
}

public void readSystemConfigFile() {
System.out.println("Reading system config files...");
}

public void init() {
System.out.println("Initializing...");
}

public void initializeContext() {
System.out.println("Initializing context...");
}

public void initializeListeners() {
System.out.println("Initializing listeners...");
}

public void createSystemObjects() {
System.out.println("Creating system objects...");
}

public void releaseProcesses() {
System.out.println("Releasing processes...");
}

public void destory() {
System.out.println("Destorying...");
}

public void destroySystemObjects() {
System.out.println("Destroying system objects...");
}

public void destoryListeners() {
System.out.println("Destroying listeners...");
}

public void destoryContext() {
System.out.println("Destroying context...");
}

public void shutdown() {
System.out.println("Shutting down...");
}
}

public class RunServer {

public static void main(String[] args) {
ScheduleServer scheduleServer = new ScheduleServer();
scheduleServer.startBooting();
scheduleServer.readSystemConfigFile();
scheduleServer.init();
scheduleServer.initializeContext();
scheduleServer.initializeListeners();
scheduleServer.createSystemObjects();

System.out.println("Start working......");
System.out.println("After work done.........");

scheduleServer.releaseProcesses();
scheduleServer.destory();
scheduleServer.destroySystemObjects();
scheduleServer.destoryListeners();
scheduleServer.destoryContext();
scheduleServer.shutdown();
}

}

The Facade Pattern

The Facade Pattern makes a complex interface easier to use, using a Facade class.

The Facade unifies the complex low-level interfaces of a subsystem in-order to provide a simple way to access that interface.

Clients communicate with the subsystem by sending requests to Facade, which forwards them to the appropriate subsystem object(s). Although the subsystem objects perform the actual work, the facade may have to do the work of its own to translate its interface to subsystem interfaces. Clients that use the facade don’t have to access its subsystem objects directly.

Please note that, a Facade same as an Adapter can wrap multiple classes, but a facade is used to an interface to simplify the use of the complex interface, whereas, an adapter is used to convert the interface to an interface the client expects. The Facade do not encapsulate the subsystem classes or interfaces; it just provides a simplified interface to their functionality. A client can access these classes directly.

ScheduleServerFacade :

public class ScheduleServerFacade {

// the server supposes to be facaded
private final ScheduleServer scheduleServer;

public ScheduleServerFacade(ScheduleServer scheduleServer) {
this.scheduleServer = scheduleServer;
}

// simplify the start api
public void startServer() {
scheduleServer.startBooting();
scheduleServer.readSystemConfigFile();
scheduleServer.init();
scheduleServer.initializeContext();
scheduleServer.initializeListeners();
scheduleServer.createSystemObjects();
}

// simplify the stop api
public void stopServer() {
scheduleServer.releaseProcesses();
scheduleServer.destory();
scheduleServer.destroySystemObjects();
scheduleServer.destoryListeners();
scheduleServer.destoryContext();
scheduleServer.shutdown();
}

}

public class TestFacade {

public static void main(String[] args) {
ScheduleServer scheduleServer = new ScheduleServer();
ScheduleServerFacade facadeServer = new ScheduleServerFacade(scheduleServer);

// use the simple api
facadeServer.startServer();

System.out.println("Start working......");
System.out.println("After work done.........");

// use the simple api
facadeServer.stopServer();
}

}

Conclusion

Use the Facade Pattern, when:

You want to provide a simple interface to a complex subsystem. Subsystems often get more complex as they evolve. Most patterns, when applied, result in more and smaller classes. This makes the subsystem more reusable and easier to customize, but it also becomes harder to use for clients that don’t need to customize it. A facade can provide a simple default view of the subsystem that is good enough for most clients. Only clients needing more customizability will need to look beyond the facade.

There are many dependencies between clients and the implementation classes of an abstraction. Introduce a facade to decouple the subsystem from clients and other subsystems, thereby promoting subsystem independence and portability.

You can layer your subsystems. Use a facade to define an entry point to each subsystem level. If subsystems are dependent, then you can simplify the dependencies between them by making them communicate with each other solely through their facades.