Lambda the Ultimate

Obviously when you define interfaces, you are allowed to create routines that take advantage of these interfaces. If, on the other hand, you are want to implement methods, how can you keep on calling these interfaces?

I guess I am being a bit thick. Sorry.

If the method can be implemented using the other methods in the interface - go ahead and implement it. You now have a shared implementation, right? If the method can not be implemented solely on the basis of the other interface methods, than how can you be sure a shared implementation is possible?

Or maybe you are thinking about a sitation in which you can not be sure in advance that sharing an implementation is going to be possible?

Lack of default implementation The final problem is the lack of default implementation. When a class extends another class, this other class can provide default implementations for all the methods. Sometimes a subclass can be created simply by extending a superclass and using the entire implementation of the superclass. Some interfaces are quite extensive, and implementing all methods can be a lot of work. This is especially irritating when only one or two methods are useful to implement in a certain situation. The interface concept forces the user of the interface to implement every method in the definition. For example, the Swing ButtonModel interface has 21 (!) methods defined. Quite often, an implementation wants to implement only a part of this interface, and it should be possible to do this.

Although AspectJ provides some relief by allowing you define a single method which cross-cuts across the classes that implement an interface, it doesn't necessarily do it in a satisfactory manner. Because the Aspect rides on top of the class definitions, the classes themselves can't override the definition. What it does allow you to do, however, is define a single implementation for all the specified classes.

Yes, of course. But my point was the the extra method can be implemented by using the other methods in the interface. (And thus it won't be part of the interface per se). Can't this be done?

Quite often, an implementation wants to implement only a part of this interface, and it should be possible to do this.

This obviously has things backwards. The point of defining an interface is to require classes that support that interface to provide all methods. Otherwise why claim you implement the interface? (Indeed, this scenario is an example of what comes under the heading of abstraction breaking in my book).

The question is not whether the class must implement all methods of the interface, but rather how one goes about accomplishing that feat. With true multiple inheritance (or mixins), the code that implements the method can be inherited from a base class - which provides not only the abstract data type, but also the code that serves as a base implementation for the subclasses.

In the case of Aspects, you are providing an implementation that can cut across classes - assuming that these classes have a common implementation which satisfies the methods stipulated in the interfaces. The idea being that if the same code is being duplicated in two places, there is probably some abstraction that is either being missed or, in this case, hard to satisfy because of the constraint of single inheritance for code inclusion.

I guess one could make the case that the Visitor pattern does have problems related to breaking the abstraction. The Visiting class must be familiar with the associated classes - doing various chores for the target classes (which is why I used the unfavorable term of parasite). But the bottom line for AOP is that they are claiming that there are abstractions which are not fully captured by the current slate of programming languages that are organized along class (or procedure/function) boundaries. They are trying to provide a release for capturing abstractions which cross-cut the hierarchies that arise in the current environments.

Whether they've succeeded in a satisfactory manner is, of course, debatable.

If the method can be implemented using the other methods in the interface - go ahead and implement it. You now have a shared implementation, right?

Um, wrong? In Java, the definition of an interface cannot contain any implementation. So there's no way to reuse the implementation of an interface method across multiple classes, other than by implementation inheritance (or cutting and pasting code, or manual delegation, etc.)

In Java, implementation inheritance is not the solution, since it is restricted to single inheritance, which prevents the use of interfaces to provide common functionality across classes otherwise unrelated by implementation inheritance.

The point of all this is that even if you ignore everything else about AOP, the ability to reuse a shared implementation of interface methods across classes otherwise unrelated by implementation inheritance is a big improvement for Java.

An article "Discussing aspects of AOP" by Tzilla Elrad, Mehmet Aksits, Gregor Kiczales, Karl Lieberherr, Harold Ossher (Comm. ACM, October 2001, pp. 33-38 -- part of the special issue on AOP) says:

"A related issue is how to work with large numbers of aspects. How do they compose? How do we think about such designs? What notations should we use for describing them? These and other related questions are ones we expect the user and research communities to explore over the next few years."

[Indeed, what if a concern weaver introduces a concern (e.g., logging) into a critical section of some other code -- which may lead to a deadlock. Are concerns associative and commutative? Concerns are in general imperative -- so they are not.]

"HO: One of the most important open [sic!] issues is semantic correctness of aspects and compositions. It has always been an issue with modular systems to ensure that modules are correct on their own and that they interact correctly when composed. The join point-based composition provided by aspect languages is much richer than the interface- or message-based connection provided by most other modularization mechanisms, complicating both specification and testing of compositions. Even specification and unit testing of individual aspects is an area requiring research.

The concept of correctness of a reusable aspect is an open issue [sic!]. We need to find good ways to express the assumptions that need to hold for a reusable aspect to work correctly in a specific context."

The correctness of AOP is still an open issue! I find it hard to take such an approach seriously.

I am not sure I agree with you on this one. Aspects are a form of abstraction breaking. When you break into someone else's abstraction you must be careful not to break something important (an invariant, a timing property, mutual exclusion, whatever).

This makes the technique problematic, but what's your solution?

When programming without a crystal ball, you must assume that future programmers will be careful when doing changes. Of course you want to minimize the chance of problems, and make maintenance as painless as possible -- but there's no way to eliminate the risk completely.

AOP seems to turn this principle around. To weave in a concern, I do need to know a great deal about the implementation. I need to examine the code to make sure I do not insert the concern in an unappropriate place. Some AOP techniques place the burden on the original programmer to specify suitable insertion points. A concern can be weaved in only at these points. However, when several concerns are to be weaved in, the problem of their ordering and interaction arises.

When programming without a crystal ball, you must assume that future programmers will be careful when doing changes. Of course you want to minimize the chance of problems, and make maintenance as painless as possible -- but there's no way to eliminate the risk completely.

When I invoke the function sin(x) in any language, I can safely assume that sin(x) will return the same result given the same value of x. I don't need a crystal ball to make and use this assumption. I'm greatly concerned with the mentality that is epitomized by the function gets() and C approach to error handling in general. Surely nobody will give gets() a string longer than the allocated buffer. Surely a programmer will test the result of malloc(). Surely the programmer will make sure that the result of strcat() will fit the allocated buffer. A quick glance at SANS security advisories shows where this approach leads to. I agree that we have to strive to minimize risk; I'm not sure that AOP does that.

Alas, there are many cases when we find ourselves breaking abstraction boundaries. The question is how to do this while minimizing risks. I am still researching this this issue, and I am not claiming AOP is a good solution. But I think that dismissing it because some risks still remain, is simply asking for too much. No abstraction breaking mechanism can guarantee this.

The first is the TOM Programming Language. TOM is an Objective-C derivative that likes to use the term Unplanned Reusability. The emphasis is placed on being able to keep class definitions Opened for reuse - trying to bend the Open-Closed Principle on the side of Open. The idea is that as Objects are reused over time, they must be open to all sorts of modifications well beyond simple subclassing. From the TOM documents:

Extensibility of classes encompasses the ability to do, without recompiling past code:

• add methods
• replace methods
• add state (instance variables), as possibly needed by new methods
• add superclasses/supertypes.

Note, that the addition of methods and state is accomplished somewhat in Objective-C via Class Categories. Like TOM, AspectJ attempts to open up the definition of classes to unplanned reuse. The most severe limitation of AspectJ, however, is that it currently supports join points and additions for which you have source code - preventing such Objective-C notions as adding methods to the base library types like Object and Strings (NSObject & NSString).

Another language that also has these notions built in is Cecil. In fact, one of the offshoot projects of that group is MultiJava:

MultiJava is a backward-compatible extension to Java that addresses some of the extensibility limitations of traditional object-oriented languages. Open classes allow one to add to the set of methods that an existing class supports without editing that class or its clients, obviating the need for tedious workarounds like the "visitor" design pattern. Multimethods generalize traditional receiver-based dynamic dispatching by allowing all arguments to be uniformly dispatched upon, resolving an asymmetry that makes some common idioms difficult to program. MultiJava retains Java's class-based encapsulation properties as well as its modular typechecking and compilation schemes.

In Cecil, the emphasis is on the terminology of multi-methods and visitors with much the same goals as AspectJ. Indeed, languages like Goo and Dylan (not to mention CLOS) are also related in their concept of multi-method delegation where new methods and properties can be added to change the type represented by a class (with type here defined in terms of state and behavior of an object). Need to add a method to a class, just define the method with the appropriate parameters. No need to worry about the base classes being Closed. Cecil also allows one to redefine the superclass/supertype, much like TOM sought to do.

In the world of AspectJ, the terminology used is Introductions, which has the same goals as TOM and MultiJava. AspectJ also tries to go beyond that and introduce the notion of Join-Points, where calls to methods can be trapped by a Join-Point and given Advice. That advice can be used to achieve any number of goals (e.g. debugging, DbC, error trapping, etc).

Anyhow, I thought I'd throw these thoughts into the mix.