The Post-OOP Paradigm
Aspects and Objects
Most of the post-OOP initiatives do not aim to supplant object-oriented programming; they seek to refine or improve or reinvigorate it. A case in point is aspect-oriented programming, or AOP.
The classic challenge in writing object-oriented programs is finding the right decomposition into classes and objects. Returning to the example of a program for playing with geometric figures, a typical instance of the class pentagon might look like this: . But this object is also a pentagon: . And so is this: . To accommodate the differences between these figures, you could introduce subclasses of pentagon—perhaps named convex-pentagon, non-convex-pentagon and five-pointed-star. But then you would have to do the same thing for hexagons, heptagons and so forth, which soon becomes tedious. Moreover, this classification would give you no way to write methods that apply, say, to all convex polygons but to no others. An alternative decomposition would divide the polygon class into convex-polygon and non-convex-polygon, then subdivide the latter class into simple-polygon and self-intersecting-polygon. With this choice, however, you lose the ability to address all five-sided figures as a group.
One solution to this quandary is multiple inheritance—allowing a class to have more than one parent. Thus a five-pointed star could be a subclass both of pentagon and of self-intersecting-polygon and could inherit methods from both. The wisdom of this arrangement is a matter of eternal controversy in the OOP community.
Aspect-oriented programming takes another approach to dealing with "crosscutting" issues that cannot easily be arranged in a treelike hierarchy. An example in the geometry program might be the need to update a display window every time a figure is moved or modified. The straightforward OOP solution is to have each method that changes the appearance of a figure (such as rotate or scale) send a message to a display-manager object, telling the display what needs to be redrawn. But hundreds of methods could send such messages. Even apart from the boredom of writing the same code over and over, there is the worry that the interface to the display manager might change someday, requiring many methods to be revised. The AOP answer is to isolate the display-update "aspect" of the program in a module of its own. The programmer writes one instance of the code that calls for a display update, along with a specification of all the occasions on which that code is to be invoked—for example, whenever a rotate method is executed. Then even though the text of the rotate method does not mention display updating, the appropriate message is sent at the appropriate time.
An AOP system called AspectJ, developed by Gregor Kiczales and a group of colleagues at Xerox PARC, works as an extension of the Java language. AOP is particularly attractive for implementing ubiquitous tasks such as error-handling, the logging of events, and synchronizing multiple threads of execution, which might otherwise be scattered throughout a program. But there are dissenting views. Jörg Kienzle and Rachid Guerraoui report on an attempt to build a transaction-
processing system with AspectJ, where the key requirement is that transactions be executed completely or not at all (so that the system cannot debit one account without crediting another). They found it difficult to cleanly isolate this property as an aspect.