Inside Taligent Technology - Framework programming

Framework programming

Another way to look at the class library-framework continuum is to think of a framework as having two additional APIs that are orthogonal to the calling and subclassing APIs: the client and customization APIs. Whereas the calling and subclassing APIs describe the mechanism by which functions are invoked,
the client and customization APIs describe the way developers use a framework's functions.

A framework's client API is employed by a programmer who wants to use the framework as it is intended to be used. Using a client API can in turn involve using both the calling and subclassing APIs, but without changing the fundamental internal operations of the framework.

The customization API is employed by a programmer who wants to modify, enhance, or extend a framework's behavior. Using a framework's customization API usually involves using the subclassing API, but in more complex ways that end up changing some portion of the framework into something completely different. However, the customization API can also involve the calling API if customizing the framework requires the programmer to provide new calling API functions. This kind of arrangement is analogous to "delegation" or "callbacks" in procedural programming.

In practice, the distinction between client and customization APIs gets blurry. A CommonPoint programmer can use a framework in a range of ways:

Use as is. Use the framework as is, like a specialized class library. For example, the CommonPoint system's Text Editing framework provides ready-made text boxes, text tools, and full-featured text-editing components that a programmer can use as is. The Text Editing framework's calling API can be used by instantiation to create standard text objects, and the calling API in turn manipulates those parts of the Text Editing framework and other text frameworks that provide those services.

Complete. Add code to the framework to implement specific capabilities. For example, the Presentation framework draws windows but not their contents. To display anything in a window, the programmer uses the framework's subclassing API to override the framework's virtual member functions that draw into the window. Similarly, to support specialized connectivity software for a particular database via the Data Access framework, the database provider subclasses from the generic classes provided by the framework's subclassing API.

Customize. Replace parts of the framework implementation. For example, the Graphics Editing framework provides standard graphics tools that allow users to create multiple objects, select them, drag them around the screen, and so on. To customize the behavior of some of these tools, a programmer can replace some of the code in the framework. It's possible to replace a little or a lot, or even the entire implementation. It's even possible to implement some or all of the code in hardware, such as the graphics rendering algorithms. In all cases the same calling API is preserved.

[Contents] [Previous] [Next]