Java Desktop

Experienced developers know many of the benefits of and motivations for using interface-based design principles. Interfaces provide for polymorphic behavior by hiding the implementation and only exposing the relevant public methods of the implementing class. What may be less appreciated is that the use of interfaces, when applied to an entire application, can provide for application isolation, while at the same time enhancing testing capabilities.

In this article we'll explore the use of interfaces at all application boundaries and gain an appreciation for why we should consider, and possibly even mandate, interface-based design principles at all application boundaries. This mandate should apply even if application requirements or application design do not call for differing behavior behind the interface.

What Is an Application Boundary?
Before we start mandating anything throughout our entire application, it would be helpful to have a better feel for exactly what an application boundary is. Consider any application you write. The application is composed of the classes that you write and the code or resources with which your application interacts. Unless you're writing an "Hello World" application, you will need to access many or all of the following resources:

• File system, library, server, database...

Although the above list is only a small subset of the many external resources that should be considered application boundary resources, it does convey the essence of the idea. Figure 1 provides a pictorial view of these application boundary resources.

Motivations for Interfaces
While many motivations drive the use of interfaces, it is instructive to describe the core motivations. As one example, consider JDBC, which makes heavy use of interface-based design principles. A ResultSet is an interface; moreover, all JDBC driver vendors must provide an implementation for the ResultSet interface. Application developers simply use the ResultSet, in most instances not knowing or caring how the underlying code is implemented. Application developers code to the ResultSet interface while the actual implementation is usually defined and configured apart from the application code. JDBC is based heavily on interfaces to support the ability to change the driver implementation without impacting the application code. Simply put, portability is the driving factor for JDBC interfaces.

Resource wrapping can be listed as a second motivation for the use of interfaces. The main intent is to support the ability to change the wrapped resource with little to no application code changes. In this sense, the motivations for resource wrapping are very similar to the JDBC example except that most resources are not based on a set of predefined interfaces as JDBC is. By contrast, different resources that deliver the same or similar functionality are not likely to have the same API. As a result, the interface for a changed resource is likely to become more of a façade-based implementation, especially if a resource change is realized.

Other application interfaces are typically chosen for the polymorphic benefits realized by an interface-based design. The application behavior is mandated by either specific requirements or by design recognizing the similarities between two or more subsystems or elements. On the application side, interface-based solutions are nearly always chosen based on required or desired application behavior with polymorphism being the driving motivation.

Lastly, application isolation should be added as another motivation for the use of interfaces. The intent of application isolation is not necessarily to support the future change of a tool or resource, but rather to support the ability to remove the resource dependency from an application. Isolation is often needed during unit testing, but is also beneficial in the early stages of development when the resource in question may not yet be available. Using interfaces at all application boundaries delivers the ability to easily plug in alternative implementations that are not resource dependant. This capability can deliver extensive benefits to a development team by eliminating the constraints imposed by some resource dependencies.

For brevity, the motivations for interface-based design are:

• Portability
• Resource wrapping
• Polymorphism
• Application isolation

Project Example, Iteration 1
Application isolation is the motivation we'll spend the remainder of this article on. With that thought in mind, let's turn to the impact of external resources on our application code base. For better understanding we'll use the retrieval of a collection of person objects from a database as our core example. In iteration 1 we'll provide an unimproved implementation. This iteration shows a small cut of the code as it might exist without the use of interface-based design principles. Using good design principles we'll encapsulate our database access by using a PersonDAO class (Data Access Object pattern) for all database access. Figure 2 shows the UML for our simplified application.

The PersonDAO class will acquire a database connection and issue queries on behalf of the invoking party, which in this instance is the BusinessFacade class (Façade Pattern). The code below shows a brief implementation of the BusinessFacade class. Note the direct instantiation and use of the PersonDAO class, which immediately ties the BusinessFacade class to the database resources referenced in the PersonDAO class.

1  public class BusinessFacade
2  {
3  public void
4  reportTodaysBirthdays()
5  {
6  Date today = new Date();
7  PersonDAO personDao =
8  new PersonDAO();
9  Collection persons =
10  personDao.getByBirthDate(today);
11  // Do what needs to be done
12  // to report on those that
13  // have birthdays today.
14  }
15  }

Being tied to the database imposes all of the following resource requirements:

• Existing network connectivity
• Database server capable of handling the connection request
• Database schema supporting the Person table
• Database data from which the query can be fulfilled

It's certainly true that we will be required to be tied to some database at some time during the development phase. However, imposing such a hard dependency for all development unnecessarily hinders other developers working outside the realm of the database. Moreover, the hard dependency can be rather easily avoided with a little forethought and a simple interface!