mobile computing, clustered computing and management of object library management [Banerji,
94]. Moreover, these problems have counterparts in system and application software for stand-
alone workstations [Krueger, 93]. As discussed below, some solutions have been suggested in the
past. However, many of these solutions are ad hoc and lacked the genericity needed to construct
extensible class libraries for other application domains. This paper addresses genericity by dis-
cussing the design, implementation and use of a framework that allows C++ class library designers
to build extensibility into their subsystems.
This framework has various specializable and easily replaceable components. In addition, cer-
tain programming guidelines that aid in gluing together the components of an extensible library are
discussed. The existing libraries for this framework and sample test cases have been built for AIX
3.2 running on IBM RS/6000s. A custom port of the AT&T cfront 3.01 was used to build the com-
ponents.
The next section discusses extensibility and its implications. The terms and technologies per-
taining to the framework implementation are then detailed. Related work is discussed in the subse-
quent section. Section 4 lays out the overall structure of the framework as well as the details of the
design principles. Section 5 discusses the programming guidelines that implementors need to fol-
low and presents a concrete example. Section 6 describes the user’s view of software, built using
this technology. The paper ends with a summary of its contributions.
2. What Extensibility really means
This section attempts to demystify the term extensibility. In order to do this, it is necessary to
list the features that usually characterize extensible software. The identification of such features
leads to a better understanding of the techniques and mechanisms necessary to support extensibil-
ity.
Extensibility implies different things to different people. Instead of using some preconceived
notion of this software property, we choose to define the essential features of extensible software.
Some of these features are obvious, while others are not. The features are:
• Separation of interface from implementation is necessary to ensure that the visible func-
tionality of a software library is not cluttered with non-relevant implementation details. Such
a feature is considered good practice, since it allows for implementation changes with little or
no client-code recompilation. Furthermore, it is a fundamental requirement for supporting
other features of extensible software.
• Tunable implementations allow design decisions to be based upon actual run-time data.
Best case scenario implementations are replaced by designs that can act upon client-provided
hints and directives. Thus, application-dependant usage information, which can never be pre-
dicted at design time, may be used by clients to fine-tune software implementations. This fea-
ture may appear to conflict with interface-implementation separation. However, as discussed
later, it is possible to simultaneously support such conflicting features.
• Multiple coexisting implementations for one particular interface allow clients to choose
an implementation that closely matches their needs. Hence, conflicting design choices may be
reflected in separate implementations, thus affording implementors the luxury of application-
specific optimizations. Clients on the other hand, are left with the responsibility of selecting
an appropriate implementation at run-time. Furthermore, this separation allows for the inde-
pendent development of different implementations of an interface. Thus, bug fixes for exist-