5.7 Exercises

EXERCISE 5.1 Managing Complexity Using Architectural Options

Consider one approach to a distributed collection management service. You could model it after the approach used by many C++ tools vendors and specify interfaces for numerous collection types (bag, list, keyset, etc.), operations to provide type-specific operations such as a comparison between objects, and commands for executing processes on objects stored within the collection. (See Figure 5.13.) Assume the distributed collection management service takes each of these characteristics to the extreme. Use the architectural options described to refactor the design into a more manageable set of interfaces.

BACKGROUND FOR SOLUTION:

Step 1: Managing elements in a collection is fairly straightforward and can be implemented using various design tradeoffs. Collection types such as bag and list queue are different ways to implement collection management behaviors. The sweep-it-under-the-rug option directs us to abstract the collection management behavior to a higher level of abstraction and not expose the specific implementation details to client applications.

Step 2: The distributed collection management service described handles three separate responsibilities: element management, type-specific comparisons, and commands. Such a design can be sliced into three simpler interfaces, each of which focuses on just one area of responsibility. Separate out the notion of generically managing collection elements, as generic elements, into a single interface that hides the details of the collection implementation. Define a separate command interface that operates on a list of objects rather than a collection. The command and collection interfaces should not have any dependencies between them. This approach to design is strictly superior to other approaches where the collection expects a command and iterates over its elements, executing a command on each item. In the new design, the responsibilities are sliced so that each command decides how to iterate over the set of elements provided rather than over the collection as a whole. The collection no longer needs to know about the command interface, and the command does not know about the collection.

Step 3: The dice-it architectural option is used to define the third interface that separates the vertical type-specific behavior from the horizontal capabilities of element management. Commands can have a standard interface that can support both horizontal commands, operations that do not refer to the specific object subtype, and vertical capabilities, where operations depend on the contents of the object. Horizontal commands would include generic operations that refer to the interface repository or perform general logging. Vertical commands would include operations that require inspection of the object contents, such as sorting and data transformations. The third interface should be a standalone version of the operation's interface, which may be used in the implementation of a command. Most frequently, it may be appropriate to collocate the type-specific operation's implementation with the command sets which require it.

The new design produced by applying these architectural options would be more component oriented and capable of supporting a greater variety of applications. However, it is less object oriented in the traditional sense, as the collection itself no longer encapsulates as much functionality. However, it provides a better base for building fully encapsulated objects, which delegate to the new collection components rather than reimplement such behavior in a new object.