Related Topics: Java EE Journal

J2EE Journal: Article

Interface All Boundaries

Providing tangible benefits to your application

Project Example, Iteration 2
In iteration 2 we seek to avoid the database dependency imposed by our thoughtless implementation in iteration 1. Adding an interface and a few support classes is all that's needed to remove our database dependency. Figure 3 shows the UML for our example application with the requisite changes.

Note the specification of the IPersonDAO interface. Implementing this interface are two classes namely "PersonDAO" and "TestPersonDAO". The PersonDAO class may remain as it was before except for designating that the class now implements the IPersonDAO interface. The TestPersonDAO class is created to return a statically defined set of Person instances in a collection. By doing so, the TestPersonDAO class will have no actual dependency on the database, but can function in place of the database-constrained PersonDAO class. The following provides the code implementation of the TestPersonDAO class:

1  public class TestPersonDAO
2  implements IPersonDAO
3  {
4  public Collection
5  getByBirthDate( Date bDate )
6  {
7  ArrayList results =
8  new ArrayList();
9  Person person = new Person();
10  // set person attributes here
11  results.add( person );
12
13  // Construct more persons as
14  // needed and add these to
15  // the returned results
16  return results;
17  }
18  }

The database dependency is removed from the BusinessFacade class when providing it with a TestPersonDAO instance rather than a PersonDAO instance. This functionality is provided for via delegation to the DAOFactory class:

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

Many possibilities exist for the implementation of the DAOFactory class. The different class instantiations could be defined by properties, the creation method could be passed a parameter, or the implementation could be based on the AbstractFactory pattern. Regardless of the chosen implementation, the important elements are as follows:

  • The BusinessFacade implementation invokes upon an interface instance rather than a concrete instance that it creates.
  • The BusinessFacade implementation delegates the construction of the IPersonDAO instance to some other entity (DAOFactory).
By applying these changes, the BusinessFacade class will only be database coupled during those times that the DAOFactory returns a PersonDAO instance rather than a TestPersonDAO instance. Defining the actual construction and return type via configuration rather than code will allow the database dependency to be removed via the same configuration.

Other Tools
One tool that exists for the purpose of removing application dependencies is mock objects. The mock objects API allows a developer to easily instantiate objects based on any interface, and to easily provide a default implementation for these mocked up objects. The mock object framework shines in the area of unit testing by allowing dependant resources to be "mocked" in a programmatic way. As such a developer can create defined software instances for required resources and allow tests to be driven from the mocked instances. This greatly supports the isolated "sand-box" environment that is so desirable for well-written unit tests.

It should be noted that the interface-based design principles proposed in this article will lay the groundwork for your application to easily incorporate and leverage the use of the mock objects framework. Whether you provide your own implementations or leverage the mock objects framework, you will have allowed your application to be configured apart from the resources that it would otherwise depend upon.

Conclusion
We've had the opportunity to explore the problems that arise when direct resource dependencies are imposed upon our application development team. The benefits of avoiding these dependencies offer compelling reasons to avoid or defer such dependencies. We've also experienced the relative ease in which these dependencies can be avoided.

In much of my development life, I've defined resource interfaces initially, provided non-dependant implementations for these interfaces, and went well along the early iteration phase or phases without ever needing to invoke upon the implementation that introduces the actual resource. As a result, my early phase development goes faster because I'm not hindered by the absence of a dependant resource. Only later in the development phase do I introduce the implementation that adds the resource dependency.

Requiring that all external resources be based on an interface adds little effort to the development timeline. Yet it provides tangible benefits to the application under development and to the application development team. Therefore, consider adding application isolation to your list of motivations when considering the use of interfaces in your application development efforts and use interfaces at all application boundaries.

As a final note, it is instructive to recognize that the techniques described in this article transcend the implementation language. Although the code examples were presented in Java, the benefits of application boundary interfaces can be realized in any implementation language.

References

  • Alur, D. et al. (2001). Core J2EE Patterns. Prentice Hall.
  • Gamma, E., et al. (1995). Design Patterns. Addison-Wesley.
  • Mock Objects: www.mockobjects.com

More Stories By Pete Whitney

Pete Whitney is a Solutions Architect for Cloudera. His primary role at Cloudera is guiding and assisting Cloudera's clients through successful adoption of Cloudera's Enterprise Data Hub and surrounding technologies.

Previously Pete served as VP of Cloud Development for FireScope Inc. In the advertising industry Pete designed and delivered DG Fastchannel’s internet-based advertising distribution architecture. Pete also excelled in other areas including design enhancements in robotic machine vision systems for FSI International Inc. These enhancements included mathematical changes for improved accuracy, improved speed, and automated calibration. He also designed a narrow spectrum light source, and a narrow spectrum band pass camera filter for controlled machine vision imaging.

Pete graduated Cum Laude from the University of Texas at Dallas, and holds a BS in Computer Science. Pete can be contacted via Email at [email protected]

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.