Working With Design Patterns: Facade

Introduction

A software system is never a perfect thing. Developers almost always must balance system quality with demand. The software must be shipped; therefore, developers must proceed with what they think is the most appropriate design.

Developers also know much more about the actual use of the software once it ships. This effect is highly evident when they build a system that requires publicly exposed programmatic interfaces, or APIs (application programming interfaces). The primary goal of an API is to allow multiple parties to re-use the software product.

If only one party intends on ever using software modules, developers don't talk about a "public API" so much, and they don't spend a lot of time ensuring that it's as well-defined and forward thinking as possible. Things are still within their control, and thus easy to change. But, once an API is out of the bag—once other developers have begun to consume it—developers lose a lot of the ability to control it.

Case in point: the unfortunate design of the Java date and calendar classes. The getter methods (getMonth, getYear, and so forth) on the java.util.Date class, introduced in Java 1.0, have been marked as deprecated since version 1.1. I recall some mumbling from Sun about an internationalized date solution, and how the Date class wasn't it.

Sun couldn't change the Date class without breaking many applications, as it was already in heavy use. So, it introduced the heavyweight Calendar class to help resolve the problem, adding support for international applications. The resulting design is difficult at best. I've encountered countless shops that created a simpler solution by building a wrapper classes around Java's date-related library classes.

The wrapper classes these teams built are facades (also typed as façades, but the former is easier to type on a US keyboard). A facade, in software design terms, is an interface intended to simplify a more complex API. Introducing a facade simplifies conceptual understanding within a system, and thus helps keep maintenance costs low. It also allows increased flexibility by encapsulating the specific APIs that hide behind the facade.

The ProcessBuilder API, introduced in Java 2 SE 1.5, is another Sun solution that often promotes the introduction of a facade. (The ProcessBuilder class provides capabilities similar to the Runtime class that's always been a part of the Java class libraries.) Obtaining output from a command line application that writes to the console requires creating a separate thread, and two threads to obtain stderr output in addition to stdout.

As a programmer who simply wants to execute a command and grab its output, I find the API for ProcessBuilder too involved. Still, the design choice for ProcessBuilder is appropriate, because it supports ultimate flexibility. For example, I might want to do something special with the stdout thread for a command that produces voluminous output. But, most of the time, I want to bury all of that thread complexity behind a facade.