The Law of Demeter has long been accepted as a proven way of increasing code's reliability and maintainability. This book develops the Law's ideas far more fully, codifies them in tools that supplement C++, and presents them as a textbook for an advance OO or software engineering course.



The Adaptive idea addresses two problems endemic to OO software. The first problem is software's brittleness. The authors identify structural "leakage" as a major cause of this problem - the spread of knowledge of one class's structure into the classes around it. That makes change riskier and more difficult, since any change within some class has some chance of requiring matching changes to other modules, in an ever-expanding ripple. The second problem addressed arises in trying to fix the first. Rather than expose its internals, a module can export methods that dispatch service requests to contained objects, in chains that can become long enough to affect performance. Flocks of these mini-methods bloat the classes that contain them, and also constrain the kinds of data structure traversals possible.



Adaptiveness starts with the "class dictionary," the map of classes in a program with the aggregation and subclassing relationships between them, represented in pre-UML notations. This brings to mind the CODASYL network-oriented databases that preceded the Relational revolution in the 1980s. That model meshes nicely with the Visitor design pattern, but adds the possibility of many link-dependent kinds of traversals of traversals of subsets inspired by the rich semantics of CODASYL database queries. The Visitor pattern requires each class to mediate traversal of its own internals, implying changes to potentially every class for each new kind of traversal. Adaptive software adds a query language to the code (which could have been done in a reflective framework). This not only centralizes each kind of traversal, but adds implicit rules and constraints that avoid the need to name every class in every traversal. As a result, one traversal rule keeps working even when massive changes alter the shape of the data network being traversed.



The Visitor objects, code fragments that execute at each node in the network, appear in the traversal definitions, not in the data objects themselves - in other words, data objects need not implement answers to every question that might be asked of them. Given a few low-level primitives in each data object, service requests are composed almost as objects themselves. This gives the Aspect-oriented flavor of Adaptive code. The big difference is that Aspect-oriented cross-cuts typically address the service entry points in each object. In contrast, Adaptive code makes its cross-cuts at the connections between objects. Instead of addressing just individual entry points, this adds the context sensitivity of objects subsidiary to specific others, or to wild-carded traversals of object networks - a real improvement in expressive power.



Adaptive software has been tried a few times commercially, with supposedly good results, but has not caught on. It's a bit "out there," would add too many new concepts to code, and would probably impose too many restrictions for most OO programmers' comfort - even if those restriction improve the -ilities of the code. Adaptive queries' wide-ranging effects also work against the Agile practice of testing isolated units, since Adaptiveness inherently handles broad and loosely-specified networks of objects. The Adaptive tools remain research oddities, adventurous and exclusive developments of single ideas rather. Wider acceptance would require the ideas to appear in building-block form so they could be incorporated into complex software development flows built around widely accepted tools. Many of the concepts appear useful; I'll probably adapt them to some kinds of reflective traversals of object hierarchies. On the whole, however, I'll file Adaptive methodology in the cabinet of software engineering curiosities.



-- wiredweird