XPmeetsAOP

AOP = AspectOrientedProgramming

xP = (well, you know that)

How might the two compliment each other?

These are my notes from the BoF? session on AOPmeetsXP? at OT2000. I have tried to make them into sentences but otherwise the first paragraph of each point is just as I scribbled them down on the day. These points were made by the participants of the BoF? whose names I have not recorded. I have made a few additional comments since then that are signed below. -- MarkSkipper

Aspects to reduce duplication: you are refactoring your code and you can see lots of duplication at the method level that you can't easily get rid of. you remove the duplicated code into an aspect and then weave it back in. ... and then unit test, of course!

Merge loop bodies: MartinFowler is against loops that do more than one thing. Early papers on AOP used loop fusion as a motivating example. Can we use AOP to get away from loops that do more than one thing?

Loop fusion is not a features that is directly supported by AspectJ though it is a paradigmatic example of AOP. Some level of separation can be achieved however if the content of a loop is a method call to which aspect advice can be attached.

Aspects might make it harder to refactor: If there are lots of aspects that advise my code this effectively reduces my freedom to refactor: advice is targeted by crosscuts that are made up of class name and method name. If I change the class to which a method belongs, or worse still, remove it and replace with another, the aspect code no longer applies.

This is similar to the dependencies that exist in inheritance, where the subclasses depend upon their superclasses and changes to one can upset the other.

This seems to be an effect of the itself being the only view of the system structure. Not having to haul the weight of design documentation -- or even long comments -- seems to me to be one of the benefits of XP, but here visibility of the impact of change is impaired by the usual presentation of text as flat files. The solution might be in the form of clever tools that show you, at source level, the effects of your advice and allowing tracability from the target code back to the aspect that augments it. This is currently available with the AspectJ distribution in the form of an emacs mode.

This requires tracibility of the effects of AspectWeaving? back to the source. At the moment AspectJ is implemented as a source code level tool but that might not always be the case. There are a number of reasons to think that byte code tools might be more appropriate but even if they were present, source level visibility of the cross-cutting dependencies is vital.

For much of the time, however, the effects of these aspect-base dependencies would become obvious: warnings from the AspectJ compiler would find some and many others would be brought to light by performing the unit tests: if the aspects implement some part of the functionality, there will be a test for it that will fail if it no longer gets woven in in the right place.

Weaving in the test code Dynamic advice could be used to reconfigure mock objects during the test process to test different aspects of the code. This could help cut down the large number of different configurations of test objects that sometimes have to be created to get coverage. The class under test may be required to call some known method of another class in different ways: a particular number of times, with particular arguments, handling a generated exception, etc. The logic inside the called method (assuming that it belongs to a MockObject for example) has to be crafted to expect and test all these different situations. This is a place where many different test concerns coincide. The different test behaviours could be configured dynamically using advice. It was reported that at present this is dealt with using complex logic inside the mock object's methods that use many flags and counters to establish the appropriate test conditions.

Complex logic in testing mock-objects is undesirable. ... Minimize the test code as much as possible and still do a good job.

Perhaps the real objects could be used to do the testing in place of the mock ones. The testing code could be woven in possibly overriding the normal behaviour. This overlooks the fact that the tests get written first so the real objects might not exist. This suggestes that perhaps even the real behaviour is just an aspect of the objects, and their testing behaviour another one. This seems to be a different way to implement the mock pattern: at present it is done using interfaces and polymorphism. It could be done with aspects, however. Would there be any advantages from doing the aspect-oriented approach?

The following procedure was suggested: look for an example that convincingly justifies the mock-object approach (see the TestingWithMockObjects paper at XP2000) and re-factor it using aspects.

An alternative solution to the same problem was suggested: prepare a general implementation for mock objects that interprets a testing spec passed in as a string. This test spec would be, in effect, a test aspect in its own language.

Plenty of ussues arise from this suggestion that are not relevant to this page but perhaps another...?

This could be that they're talking about "mixins" which are supposed to be very like aspects, so it's not a great argument for not having aspects (i.e. smalltalk has them, they're were invented 20 yearsd ago, but they're called something else, but since nobody uses smalltalk nobody discovered them, moan moan moan...).

A better explaination might be that if you look at the squeak E-Toys support which makes heavy use of events, it's easy to add behaviours to a morph by adding scripts (behaviours) to the morphs player. So maybe if you program in a looser coupled style using events, the argument is that you might not need aspects. This is something which has only just occured to me. I also like the notion, as I've always been worried that aspects might just be a way to hack in functionality to code instead of refactoring it to support these things. I'd be interested in talking with MarkSkipper about the EventsInsteadOfAspects?. -- OliBye

Aspects are about non-invasiveness/obliviousness. They donot actually touch the code that they advise.