email article printer friendly

The Philosophy of Interface-Driven Design
Making life simple for clients is your ticket to robust software architectures
by Jason Byassee

November 2003 Issue

O bject-oriented (OO) design is synonymous with a multitude of attractive buzzwords: reusable, modular, scalable, extensible, and so on. Moving from a theoretical view to practice is not straightforward. How do we design applications that will yield these characteristics? The bad news is that it is often not easy. Robust designs are difficult to achieve. The good news is that you can incorporate a simple design philosophy that will almost transparently migrate your designs toward these goals. In addition, this philosophy will promote seamless exploitation of some OO design patterns in your applications. I call this philosophy Interface-Driven Design (IDD).

When you are given requirements and faced with building a software component, what do you first think about? Experienced developers will often read the requirements and begin immediately to "think in Java." They will mentally step through various strategies to provide the necessary functionality. This process tries to answer the implementation question. Let's take a look at an example.

Imagine working on a software application for a personal organizer (organize files, maintain a contact list, record appointments, and so on). You are tasked with building a software component that models an address book to maintain names and addresses of contacts. The ideas that come to mind here might be: 1) A collection is needed to maintain the information. You can employ a java.util.Map to maintain key-value pairs, where the name serves as the key and the address is the value. 2) An implementation class is needed to encapsulate the data structure and contained information. An AddressBook class can be built to encapsulate the java.util.Map and provide add(), find(), and remove() methods. See Listing 1 for an implementation of this approach.

Most of us work in environments where requirements are fuzzy. Requirements provided by the customer are often written at a high level. Software developers need requirements at a lower level (derived requirements) to design and implement software components. Any time we are working with derived requirements, they are open to reinterpretation and/or modification.

Sometime after the class is published and other developers on the project begin to use it, you discover that contact e-mail addresses and phone numbers need to be maintained by the application (think about how often similar situations occur in the real world). The logical place for this new contact information is the AddressBook class, but changing this class has consequences. There are three approaches that will accommodate the new contact information: change the add() method signature of the AddressBook class to accept two additional strings (email and phone); overload the add() method signature of the AddressBook class, where the overloaded implementation has four parameters (name, address, email, and phone); or finally, implement a new class to hold the e-mail addresses and phone numbers.

The first option will break many clients that use the AddressBook class. The class is not extensible in its current implementation. In addition, the AddressBook implementation that uses the HashMap for name/address pairs breaks. It does not work in its current form because two additional parameters need to be maintained. The second option may be the best; although, each overloaded method reduces readability, and the class could get ugly if we discovered more AddressBook candidate items down the line (more overloaded methods). As in the first option, we have the same problem of breaking the AddressBook implementation. The third option will still support the HashMap implementation, but it spreads contact information between two classes; this solution hinders reuse and modularity.