Aspect oriented programming and implicitness

Question

Lets suppose that I have a class which represent an image and has a number of methods.

class Image
{
    circle(x,y,radius,color);
    square(x,y,w,h,color);
    floodfill(x,y,color)
    clear();
}

Furthermore, I want to have undo functionality. A simple way of implementing this is to keep a list of all the actions that have been performed. When I undo, I just re-run all of the actions. One solution would be to implement an aspect, something like this:

aspect ImageUndo
{
    on Image::circle, Image::square, Image::floodfill
    precall(object, args)
    {
         object.actions_list.add(args)
    }
}

Essentially, this aspect has now modified the behavior of Image. That gives me concern. In particular, another programmer unfamiliar with the existence of ImageUndo aspect may run into the following problems:

1. He adds a method, and it does not work with the undo functionality.
2. Attempting to debug the undo mechanism, it is not clear where the actions_list get added to.

On the other hand we could have

class Image
{
    @undoable_action
    circle(x,y,radius,color);

    @undoable_action
    square(x,y,w,h,color);

    @undoable_action
    floodfill(x,y,color)

    @undoable_action
    clear();
}

Which does not bother me as much because it gives an idea of where to look for the undo code and makes is so that the new coder will probably notice it an automatically add it to a new method.

To summarize: aspects (at least those like the one I showed) seems to bring "implicit magic" into what code does. It seems to me that the implicitness is dangerous and we should really make it explicit.

Are there good reasons for the implicitness? Do people who actually use AOP write code that does this sort of modification?

Note: this is a reworking of Are certain problems solved more elegantly with AOP? which was closed because my previous version came across, unintentionally, as ranting.

Answer 1

Classes that implement cross-cutting concerns have nothing to say about the core functionality of classes being AOP'd. That's the core idea here.

Your example is one of an undo action. Let's take it a step further: we will make a deep copy of your class and store it somewhere. If we want to perform an undo, all we have to do is reverse the deep copy. This will "roll back" the class to its original state. You don't even need to annotate the class members to make it work (although you could annotate the class itself if you wanted the deep copy to operate automatically).

Here's my question: Does this deep copy process have anything at all to do with the primary functionality of the class being deep copied? Does the deep copy even care what the class does?

Serializing and deserializing objects are another example of this. The serialization process has no knowlege of the behavior of the class, and the objects being serialized have no knowledge of the serialization process. It's a powerful decoupling tool.

Answer 2

One thing to point ou tis that the code isn't being modified via the aspects, it's being extended. It may be semantic, but the distinction is important, especially when considereing the open/closed principle.

Now, from what I can tell (looks like aspectj maybe?), your first example applies the aspect to the methods at the declaration of the aspect, wherease your second example applies the aspect via attributes on the methods. The problem you seem to have is one where anyone extending your code might not be able to figure out how to include undo into their additions using the first example.

1. Documentation is there for a reason. So write some for your consumers.
2. Use a different design to implement the functionality for them.

I believe that something like the following will work:

public abstract class ImageOperation
{
    @undoable_action
    public abstract void Action(Image img);
}

public class Flood_Fill : ImageOperation
{
    public void Action(Image img)
    {
        // flood-fill
    }
}

Now, having abstracted away the image operations, you can supply ImageOperation in a different .dll than your program, and you can use it as the base for ImageOperation plugins, so that others don't need to see your code at all to produce an operation, and you still implicitly provide undo for them.