OO design principals state that classes should be open for extension and closed for modification. I suggest that this concept should be applied also to aspect concerns. That is there should be a strict and regimented protocol via which one can change the other both statically (via weaving) and dynamically (via data transfer).

One of the key drivers behind AOP is that concerns can be separated. However separate concerns are free to change one another, breaking the encapsulation of that concern. I believe that current AOP protocols are too lenient in the ways that they facilitate and condone the modification of static and dynamic code constructs in other concerns. This causes maintenance and debugging issues as it provides the potential for one concern to critically alter another in ways that are not directly apparent when considering a single concern in isolation.

One of the key tools of OO is the ability to encapsulate objects thus segmenting (linear) concerns within an application so that they can be considered dependable once tested. AOP offers many mechanisms though which encapsulation can be broken this undermines the one of the key benefits it offers: The ability to separate (and not have to worry about) different concerns in the application.

I believe the solution lies in moderating or marshalling the boarder between an application’s concerns. This increases the visibility of data changes made across concerns by reducing the means by which data changes can occur. This in turn increases the encapsulation of the concern making it easier to make changes without having to retest others.

Complete encapsulation of a concern is not possible as no two concerns are ever really orthogonal.  There is always a need for interaction between them. However providing too much control to the programmer implies the maintenance and encapsulation issues mentioned above. Also most notably there seems little good argument for one concern to be able to affect another.

Dynamic proxies partially address this problem as they allow decoration of objects with code from another concern. However they provide only limited join points (i.e. only those exposed through public interfaces) and are this not suitable for complex multi concern implementations.

What is required is:-

    * A method for specifying join points within an application

    * A method for adding functionality at join points

    * A marshalling methodology that prevents one concern from altering another without that concern specifically knowing about it.

I take the view that one concern is considered dominant and tertiary concerns bolt into it. Tertiary code is coded into a set of classes as if the coding was being performed in that class itself except that all interactions are passed by value. HyperJ comes closest currently to this aim.