Diagnosing Java Code: Designing extensible applications, Part 1

Black box, open box, or glass box: which is right and when?

Eric Allen (eallen@cs.rice.edu), PhD Candidate, Rice University

Eric Allen has a bachelor's degree in computer science and mathematics from Cornell University and is a PhD candidate in the Java programming languages team at Rice University. Before returning to Rice to finish his degree, Eric was the lead Java software developer at Cycorp, Inc. He has also moderated the Java Beginner discussion forum at JavaWorld. His research concerns the development of semantic models and static analysis tools for the Java language, both at the source and bytecode levels. Eric has also helped in the development of Rice's compiler for the NextGen programming language, an extension of the Java language with generic run-time types. Contact Eric at eallen@cs.rice.edu.

Summary: In this and several upcoming installments of Diagnosing Java Code, Eric Allen focuses his discussion on considerations involved in determining how extensible a new system should be, when extensibility is best applied, and how extensibility relates to other factors, particularly testability. In this first article, he examines the various ways in which a software system may be extensible and in what contexts each form of extensibility is most useful.

View more content in this series

Tag this!

Date: 25 Sep 2001
Level: Introductory
Also available in: Japanese

Activity: 2656 views
Comments:

With the growing demand for software systems that can cope with the increasingly diverse tasks of information processing, it is tempting for a software company to find ways to reduce the production costs of a new code project. One of the most obvious ways to do this is to increase the degree to which code from other projects can be reused.

With that in mind, two of the more common questions to arise when programmers design a new system are:

How extensible should the system be?
How extensible can I make the system?

Reusing code is best done if the original system was designed to be extensible. Otherwise, the difficulties of reusing code can easily negate any productivity gained. But, designing for extensibility adds in all sorts of new considerations to software design.

Types of extensibility

Black box extensibility. Extending an existing system without directly extending the original code, usually via a wizard or configuration language. Example: Any program that allows for user-defined scripts or macros.

White box extensibility. Extending an existing program by adding to source code in the following two ways:

Open box extensibility. The original source code can be viewed and modified. Example: Open source programs. Note: A problem arises when the source code is maintained externally; you may constantly have to re-fuse your extensions with the new iterations of the program.
Glass box extensibility. The original source code can be examined, but not modified. Example: Some testing programs, such as JUnit. (Although you can't alter the source code in JUnit, each test you construct with it is like an extension of the base code.)

In this article, I'll discuss some of the ways in which a software system can be made extensible for future projects.

A caveat

Before going any further, let me clarify that I'm not advocating design for extensibility in all cases, or even in most cases. Many of the design choices that facilitate extensibility will often hinder other considerations, such as performance or testability. The most testable systems are often the simplest ones, but designing for extensibility can often add a great deal of complexity to a system.

Fortunately, there are also times when the most extensible design is also the simplest, but such an alignment of considerations is all too rare.

For this reason, I suggest employing strategies for extensibility only when you are certain that the advantages will outweigh the costs incurred. This usually means that you know the system will be extended in a certain way.

Often, in the extreme programming literature, the addition of extensibility is compared to the purchase of a stock option: you purchase the option early so you can easily extend the system at a later date. If you eventually exercise this option, you can win big-time.

But if you never exercise the option, then you're out the cost of the option with nothing to show for it. So, "Buyer beware!"

Next, let's look at the various ways in which the term extensibility is defined. When discussing the extensibility of a program, there are essentially three different types of extensibility to which we are referring -- black box extensibility and two types of white box extensibility. Figure 1 illustrates the differences in extensibility type.

Black box extensibility

Black box extensibility refers to the ways in which a program can be extended without directly extending the original code. This is done usually through the use of a configuration language or wizard that leads you through the extension of the system.

One example is a tax program that includes a configuration language for specifying the various tax forms. When the government issues new forms, the system can be extended simply by specifying the structure of the new forms in the configuration language.

Black box extensibility is most applicable to the study of proprietary components and frameworks in which the business model of the original development team requires both that:

The program is proprietary (not open source)
External developers have some degree of flexibility in customizing the functionality of the component

Programs that allow for user-defined scripts or macros (such as Emacs, MS Office, and the like) are examples of systems with black box extensibility.

White box extensibility

White box extensibility, in contrast, refers to the ways in which a program can be extended by modifying or adding to the source code. I like to distinguish two subcategories of white box extensibility: open box and glass box.

Open box extensibility

Don't miss the rest of the "Designing extensible applications" series

Part 2: "Examine when, where, and how glass box extensibility works best" (October 2001)

Part 3: "Examine when, where, and how black box extensibility works best" (November 2001)

Part 4: "Examine how S-expressions provide a lightweight form of black box extensibility" (December 2001)

When modification of the original source code is allowed, I call the system open box extensible. Of course, in principle, such a program may be arbitrarily extended, but not all extensions are of equal difficulty.

The study of open box extensibility is concerned primarily with how to facilitate various kinds of extensions, given the ability to change the program when necessary. This is exactly the form of extensibility most relevant to a development team when producing the next version of their own product.

In some cases, this type of extensibility may also be of interest to developers attempting to take advantage of existing open-source software. But extending an open-source system in this way is riddled with problems.

The most glaring problem is what to do when the "official" maintenance team decides to release a new version of the software. Fusing their changes with yours can be difficult and time consuming. Even if the system is modular enough that the actual code you've changed doesn't conflict, it is difficult to be sure that no assumed invariants of the new code are broken by your changes (although this problem can be ameliorated to a large extent if the code is shipped with unit tests).

Glass box extensibility

Glass box extensibility refers to the ways in which a software system can be extended when the source code is available for viewing, but not modifying.

Because of the problems discussed above with altering externally maintained open-source code, it is advisable to use only glass box extensions on such code whenever possible. A great example of a popular, glass box extensible system is JUnit. Every unit test can be viewed as an extension of the original code base.

Figure 1. Each approach depends on how accessible the code is to the extender

What's this?

This little timesaver lets you update your My developerWorks profile with just one click! The general subject of this content (AIX and UNIX, Information Management, Lotus, Rational, Tivoli, WebSphere, Java, Linux, Open source, SOA and Web services, Web development, or XML) will be added to the interests section of your profile, if it's not there already. You only need to be logged in to My developerWorks.

And what's the point of adding your interests to your profile? That's how you find other users with the same interests as yours, and see what they're reading and contributing to the community. Your interests also help us recommend relevant developerWorks content to you.

View your My developerWorks profile

Return from help

Close [x]

Help: Remove from My dW interests

What's this?

Removing this interest does not alter your profile, but rather removes this piece of content from a list of all content for which you've indicated interest. In a future enhancement to My developerWorks, you'll be able to see a record of that content.

View your My developerWorks profile

Return from help

static.content.url=http://www.ibm.com/developerworks/js/artrating/

SITE_ID=1

Zone=Java technology

ArticleID=10589

ArticleTitle=Diagnosing Java Code: Designing extensible applications, Part 1

publish-date=09252001

author1-email=eallen@cs.rice.edu

author1-email-cc=