|
Plug-in to Reusability in Java
by Keld H.
Hansen
Introduction
As a Java programmer with an object oriented brain you're used
to handling classes in your programs by instantiating them and
using their methods:
. . .
Employee e = new Employee();
e.setBirthday(someDay);
. . .
To make your programs more flexible it's often a good idea to
start by defining Interfaces for the classes you use. By
referring to the Interfaces instead of specific classes, you can
make your program more general:
. . .
Person p = getPerson();
p.setBirthday(someDay);
. . .
If Person is an Interface and
Employee implements it, then
getPerson() could return an Employee
object, but also many other objects, as long as they implement
the Person Interface. So with a small
modification we've made our two-line program more general.
getPerson() could be implemented in many ways, it
could for example get the name of the class implementing
Person from some source, maybe a properties file:
public Person getPerson() {
Properties props = new Properties();
. . .
String className = props.getProperty("class_name");
Person p = (Person)Class.forName(className).newInstance();
return p;
}
In this article I'll try to push this idea further, by first
defining Interfaces for several important classes used in an
application, and then, giving the actual class names in a
parameter file read by the application on start-up. This
application design is often referred to as a plug-in
architecture, where the parameterized classes are the plug-
ins.
A sample application
To show you how a plug-in architecture could be implemented
we'll consider a simple case. Assume that we must develop an
application which reads temperatures for some cities from some
source, and delivers some of the temperatures to one or more
targets. The design criteria we'd like to meet are these:
- it must be simple to use a new module that reads the
temperatures from some source
- it must be simple to use a new module that delivers the
temperatures to new targets
- we must be able to handle temperatures in various formats,
both on input and output
- we'd like to have a core module that won't change if the
modules handling source or targets change
As we will see shortly it's possible to meet these goals by
using a plug-in architecture.
The core module -- which we'll call the driver -- is the
user of the plug-ins. As said above the idea is that each plug-
in implements a specific Java Interface, which the driver knows.
The driver therefore may call methods from the Interfaces,
without having to know which specific plug-in is being used. The
plug-ins used are defined in a parameter file, which the driver
has access to. It's the drivers task to instantiate the plug-ins
and use their methods.
Step 1: Define the tasks in your application
We'll work with three tasks:
- read temperatures
- transform temperatures (from input to output format)
- send temperatures
These three tasks will correspond to our three plug-in
types. Each plug-in will output data that is used as input
to the next plug-in.
New on the Java Boutique:
New Review:
Time Management Made Easy with the Quartz Enterprise Job Scheduler
Why not just use the Java timer API? This open source scheduling
API boasts simplicity, ease-of-integration, a well-rounded feature
set, and it's free!
New Applet:
Reverse Complement
Reverse Complement is a simple applet that converts DNA or RNA
sequences into three useful formats.
Elsewhere on internet.com:
WebDeveloper Java
Lots of Java information on webdeveloper.com
WDVL Java
Thorough Java resource at the Web Developer's Virtual Library.
ScriptSearch Java
Hundreds of free Java code files to download.
jGuru: Your View of the Java Universe
Customizable portal with online training, FAQs, regular news updates, and tutorials.
| 
