The design of the DB Interface Module uses the Interface/Implementation paradigm. Interface classes model objects in the application domain. Each interface class has an associated implementation class, which is used to implement the semantics defined by the interface class.

This paradigm is familiar to most C++ programmers. For example, many beginning texts present examples of simple classes like string that follow the paradigm. A typical string class might be designed as an interface class that defines the semantics of the class and contains a pointer to a reference-counted implementation class, which provides the services of data storage, memory management, and so on.

The public class hierarchy of the DB Interface Module consists of a set of interface classes that are concrete, as opposed to abstract. These concrete classes function as is without requiring further derivation. As interface classes, they do no work and store no data themselves. Instead, each interface class instance consists of a pointer to an implementation class instance, and forwards all function calls to it. The implementation classes are not part of the public hierarchy. Only the interface classes are visible to the application programmer.

The interface classes are divided into classes that contain a pointer to a database-dependent implementation and those that do not. In general, classes that model database concepts, like RWDBTable and RWDBSelector, have pointers to database-dependent implementations, while classes that model database-independent concepts, like RWDBBlob and RWDBExpr, do not. Table 1 shows the class hierarchy of the public classes of the DB Interface Module. Note that the class implementations may also use private inheritance.

Note that all implementation classes of the DB Interface Module database-dependent classes can be considered abstract classes, containing virtual functions. These virtual functions will be overridden in the derived classes that make up the database-dependent Access Modules.

For example, class RWDBDatabase is an abstraction that represents a database. It offers a rich set of semantics: you have access to database objects like tables, views, and stored procedures; you can manage multiple connections; and you can use database definition language (DDL) constructs, among other things.

These semantic elements represent features common to all databases. However, the way a feature is implemented for any particular database depends heavily upon the API provided by the database manufacturer. Consequently, RWDBDatabaseImp, the implementation class associated with RWDBDatabase, is an abstract base class for a family of database-dependent implementation classes—one implementation class for each database manufacturer that SourcePro DB supports. These database-dependent implementation classes make up the Access Module for the particular database. Figure 2 shows this relationship.

Notice also from Figure 2 that classes RWDBDatabase and RWDBDatabaseImp reside in the DB Interface Module, while RWDBSybCtLibDatabaseImp and RWDBOCIDatabaseImp reside in separate DB Access Modules. This is the key to database portability in SourcePro DB. The DB Interface Module—and therefore, your application—doesn't care which databases it works with. The Interface Module serves as a software backplane for plugging in different Access Libraries interchangeably. When using shared libraries or DLLs, you can even plug in Access Libraries at runtime without relinking your application.