24.4. GUIDELINES FOR ASPECT-ORIENTED DEPENDENCY MANAGEMENT There are many reasons to choose aspect-oriented designs, but from the perspective of managing unhealthy dependencies, we can derive a number of guidelines from the examples of the preceding sections. 24.4.1. Object-Oriented Indirection First, the advantages of object-oriented indirection for reducing dependencies are still significant. Choose object-oriented dependency management (often just a simple object-oriented interface to hide an implementation) under these circumstances: When dependencies cross subsystem boundaries (published interfaces). At the package or subsystem level, hide private classes behind public interfaces in order to avoid publishing implementation details outside the subsystem. When an interface has separation-of-concerns value beyond dependency management. Inside a subsystem, maintain a clear layering of the classes and interfaces to hide external dependencies. For example, classes near the "top" of a subsystem might depend on an XML library, while those near the bottom might depend on a data access library. An object-oriented hinge point in between keeps changes in either external dependency from breaking the whole subsystem. When behavior is truly polymorphic (has multiple similar services). If an interface has multiple implementations (e.g., Product in the Factory pattern), the need for a polymorphic interface goes almost without saying and is not negated by aspect-oriented techniques.
24.4.2. Aspect-Oriented Indirection Manage dependencies with aspect-oriented hinge points under these circumstances: When an object-oriented solution would intrude into un-owned code. Often, the lines of modularity in a system have as much to do with organizational divisions as with technical ones. When this is true and a service does not provide needed interfaces, an aspect-oriented design can avoid an ugly direct dependency. When an object-oriented design would break dependency principles. Some object-oriented designs are obsolete (e.g., Visitor) or at least debatable (e.g., Strategy) when aspect-oriented alternatives are available. When a single object-oriented service design would not meet the needs of all anticipated clients. A significant advantage of aspect-oriented designs is that different clients can have different views into a service without cluttering that service with an overly extensible or flexible interface ready for all comers. When the dependency needs only a simple notification or other "callback" connection between client(s) and service. The advantages of aspect-oriented notification come close to making it the default choice in a new design of this kind. When a service sees use by many similar clients. Almost by definition, object-oriented indirection is the better choice for a service with multiple implementations, and aspect-oriented indirection is the better choice for many clients with similar or related behavior.
24.4.3. Combined Object-and Aspect-Oriented Indirection Finally, there are circumstances when it is best to combine object-oriented and aspect-oriented dependency management techniques: When an object interface is expected by external code but an aspect-oriented solution makes sense otherwise (e.g., aspect-oriented factory). When one concern (e.g., object construction) is best handled by aspects, but other concerns in the same object hierarchy are better modeled by polymorphism (e.g., domain object behavior), the obvious solution is to apply the right technique for each concern. To provide a reusable target for mechanisms with many optional aspects in addition to a primary client/service connective aspect (e.g., Observer with thread safety, event bundling, and event tracing). Sometimes, it may be best to provide a coordinated library of base objects, interfaces, and aspects in order to separate the detailed concerns of a mechanism from a further aspect-oriented application of that mechanism to a particular dependency.
In general, the reasons to combine aspect-oriented and object-oriented indirection amount to minimizing the overall rigidity of a design. There is much yet to learn about the best ways to combine object-oriented and aspect-oriented indirection. Some future book on "Multi-Paradigm Design with Aspect-XX" will be an interesting read. |
