The L shape in the center of Figure 16 represents the framework, which consists of multiple classes that cooperate intimately to address a particular problem domain. The box above the framework represents a program using the calling API. This program could be another framework or any program that requires the services of the framework in the center of the figure.
For example, the Data Access framework in the CommonPoint system allows
applications to access multiple Structured Query Language
(SQL) software modules by using a single calling API that resembles a class
library. Programmers can instantiate standard connection, command, and statement
objects with little modification and use them to construct their own queries and
database documents. Programs constructed with the calling API work the same way
with all SQL connectivity software modules supported by the Data Access
framework.
The box underneath the framework in Figure 16 represents a program using the
subclassing API. The subclassing API looks very different from the calling API. A
programmer uses the subclassing API by subclassing existing classes and
overriding particular member functions. The resulting code is called by the
framework when it calls those member functions polymorphically.
In the Data Access example, the subclassing API consists of virtual member
functions for a generic implementation of the SQL interface. The appropriate
innards of the generic interface are exposed, via the subclassing API, so that
they can be customized for different SQL connectivity software modules. Because
the calling API is the same for different software connectivity modules (such as
ODBC or SQL*NET") that are subclassed from the Data Access subclassing API,
programs that use the calling API work the same way no matter which subclassed
SQL software is actually providing the services. This is the essence of
polymorphism.
In practice, the distinction between the calling API and the subclassing API is
not always as straightforward as Figure 16 suggests. A member function called as
part of the calling API may itself be overridden by a function provided by the
same program's extension of the subclassing API; or it may end up calling other
functions that the program has subclassed via the subclassing API; or it may use
member functions from calling APIs for other frameworks that in turn rely on
virtual functions that the program has extended via those frameworks' subclassing
APIs.
Various approaches can be used at the same time by a single program, as discussed
in "An application is an ensemble of framework-based code," beginning on page 76.
However, CommonPoint programmers don't need to deal with the full complexity of
multiple frameworks. The cpProfessional development environment, which is
introduced in Chapter 5, facilitates browsing through the classes provided by
various frameworks to pick out and assemble the parts you want to work with.
[Contents]
[Previous]
[Next]