[Contents] [Previous] [Next]

Calling API vs. subclassing API

Frameworks can be thought of as having two APIs: a calling API, which resembles a class library, and a subclassing API, which is used for overriding framework member functions. The calling/subclassing distinction describes the mechanism by which functions are invoked: call or be called. Figure 16 provides a simplified picture of the way programmers use these APIs.


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]

Addison-Wesley Publishing Company, Copyright©1995 by Sean Cotter and Taligent,Inc. All rights reserved.