Scenario

[Previous] [Next]

Without a doubt, systems evolve. Evolution of a system is mainly due to the demand for new features or enhancements to existing ones. A good system design abstracts the roles of the various objects in the design such that the defined relationships between the objects remain static. These abstractions are manifested in the form of interfaces. Concrete examples of these interfaces are the classes that implement them. Dissimilar classes can implement a single interface differently. Unique system functionality results from the various implementations of the interfaces. This sort of system design is called a framework.

A framework dictates the roles and relationships of objects within a system and usually provides built-in behavior (known as the default feature set). Using the Object Factory design pattern, a framework allows you to introduce unanticipated new features or enhancements to a system in a nonintrusive manner. For example let's assume that you've built an application that interacts with a Sybase database server. Currently the users must physically connect to the network from their desktop computers to run the application. However, you have been getting numerous requests from users who want to run the system off-line on a laptop computer while commuting on lengthy train rides to and from the office. You decide that a Microsoft Access client database is the suitable candidate for off-line access. Because both databases support structured query language (SQL), interaction between your application and the database is identical. What isn't identical is the method by which communication on a more rudimentary level is carried out. For best performance, Data Access Objects (DAO) is the most appropriate choice for communication with Access, and Remote Data Objects (RDO) for Sybase. (This problem has been resolved by Microsoft's development of ActiveX Data Objects [ADO], which provides a single ideal solution for both worlds. For the sake of making a point, let's assume ADO doesn't exist and that DAO and RDO are the only two database object models developed by Microsoft.) In order for your application to provide the Access database off-line feature, or any other feature that requires accessing some other data source, you need to build a data acquisition framework that I will refer to as universal data objects (UDO). UDO will define interfaces that the client application can use to successfully manipulate data from any source. The details of how data manipulation instructions are transmitted to the data source are encapsulated in concrete classes that implement the interfaces provided by UDO. The Object Factory design pattern permits the development of various database implementations within a framework, as shown in Figure 8-1. A client application can use this framework in a plug-and-play fashion.

Figure 8-1. The universal data objects (UDO) framework incorporates the Object Factory design pattern to permit plug-and-play of distinct database and resultset implementations.