4.8. Exercises

Exercise 4.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 4.27.) 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.

Figure 4.27. Distributed Collection Management System


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

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 which hides the details of the collection implementation. Define a separate command interface which 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 the collection. The collection no longer needs to know about the command interface, and the command does not know about the collection.

3.
The dice it architectural option is used to define the third interface which separates out the vertical type-specific behavior from the horizontal capabilities of element management. Commands can have a standard interface which can support both horizontal commands, operations which 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 which refer to the interface repository or perform general logging. Vertical commands would include operations which 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.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.128.168.87