Components For Software Development

Since the advent of structured high-level (so-called 3rd generation) languages
decades ago, there's been little advance in improving the productivity of
programmers. Fourth generation languages have provided niche productivity
improvements, in the form of "little languages" for domains like database
management and graphical user interfaces, but these are not robust
improvements; as soon as the task moves slightly outside the targetted
domain, the programmer is reduced to line-by-line coding.

There's been a long-running effort to increase everyday programming
productivity through the use of software components; the most common
parallel is to electronic components like chips, or even to mechanical
components like nuts and bolts. Every other field of engineering seems to
have catalogs of standard parts, why not software? On a coding level the
hope is that one will replace 100-line-long routines by 5-component-long
routines, with components drawn from standard catalogs.

Despite the fact that new attempts have sprung forth at a regular pace ever
since the first catalog efforts of the late 60's, componentware hasn't become
part of everyday programming. VBXs are a 4GL-ish exception to the rule, but
it's still true that mainstream programming involves primarily line-by-line
coding. 3rd-party libraries have been another reuse attempt, notorious for
being buggy with poorly defined interfaces; in the end they often get in the
way more than they help.

Despite the common wisdom that accomplishing reuse is a nontechnical problem,
in fact our programming languages haven't permitted the reuse of small pieces
of code; the only real mechanism for building fine-grained components into a
system has been to design a new language with the features designed in. Since
the adoption of a new language takes a long time, one gets new batches of such
minicomponents on a timescale of years rather than the days or weeks the
real use of component-style programming demands.

The Newest Attempts

Recently language features have made component-based programming more
possible; STL [Kef95]
is a true composition language based on C++'s template feature,
providing component capabilities with the efficiency needed for practical
projects [Jaz95]. Although STL is an
algorithmically-oriented mess, and although it provides only a single catalog
of parts, it is true componentware.

Batory's ongoing work
[Bat92,Bat93,Bat95,Sin93] pushes further in the same direction. He is
working to define what a component interface must look like: hiding of
implementation detail, reuse of common interfaces, and layered interfaces for
plug-in components at many levels. He uses special language constructs
and tools for guided component combination. The newer work adds refinements
like extensibility to otherwise common interfaces.

But the advances that will affect most programmers
are being made in the commercial object models:
CORBA,
SOM, and COM. These language-independent models, working hand-in-hand with
C++, Java, and other OOPLs, bring the idea of the interface to center stage.
Implementations written by different companies, in different languages, can
now work together through a plethora of interfaces. The operating system
is becoming an ever-growing API.

Fine-grained Componentware

The key idea behind component programming is the interface; the added
efficiency benefit of inlined combination a la STL is a bonus to make it
practical on a fine-grained scale.
Each line of code is written with swappability in mind. Every module
is designed to be part of a shared interface, even if only one
plug-in part for that interface currently exists. This results in a
plethora of micro-interfaces (nanofaces?) throughout the program, seams
along which the program parts can be rearranged at a variety of levels.
Each interface is clearly defined with IC, giving hundreds of well-defined
access points for later programmers.

The goal is to think about combining interfaces into common ones from both
directions: multiple callers into the interface, and multiple implementations
of the interface. For instance, a new data type address the first goal:
many uses can share a single code base. A device driver interface addresses
both goals: many users access it, and many drivers implement it. Try to
think in these terms for all your interfaces.

The bottom line is that component-oriented software design has little to do
with lines of code and much to do with the definition of new interfaces.
The quality of the product depends on the interface designer's ability to
see the underlying patterns and combine them into the program's
conceptual seams.

Larger-grained Componentware and Java

But in the world of bigger components shared among many companies,
a world where interpreted languages are often used to glue the parts together,
the level of efficiency that STL seeks is pointless. The procedure calls
used by COM are more than efficient enough, there's no need to make things
messier by trying to invoke inlining. In this world, object models like
COM in combination with the interface-specifying abilities of Java form a
perfect match, with components implemented in whatever language appearing
to the Java programmer as indistinguishable from Java classes.

This is the sweet spot in the componentware continuum, the happy medium where
reuse is most effective with the least complication for the programmer. And
Java is both fish and fowl, perfectly suited to swim in the murky network
waters while providing the free-flying features that language mavens crave.
It's the future.

References

[Bat92]
D. Batory, S. O'Malley,
"Review of The Design and Implementation of
Hierarchical Software Systems With Reusable Components",
to appear in ACM Trans. on Software Engr. and Methodology,
Oct 1992.