This is not realistic, because many cross-cutting concerns are tightly integrated with other code in their module (e.g. are not orthogonal) and are hence difficult to cleanly extract and encapsulate as aspects, or are difficult to consider without also considering other cross cutting concerns.

Dimensions rarely compose cleanly on top of each other – marshalling and security are two dimensions of concern frequently treated as orthogonal aspects of some base system in examples. These dimension are in fact closely related, difficult and dangerous to consider in isolation.

Cooperation with OO: While AOP is often proposed as a complement to OOP, little work has been carried out to understand the implications of AOP constructs like advice on the objects they are related to. In particular, the contracts of objects as expressed through pre-conditions, post-conditions and class invariants.

One obvious solution to this problem is for the programmer implementing an aspect to ensure contracts are unaltered by new aspect functionality. This calls into question the usefulness of “open world” AOP-style quantification. What understanding can the aspect author have of a class (s)he has yet to examine?

The need to understand the contracts of classes increases the coupling between the aspect and the underlying class, which diminishes the modularity benefits of AOP.

COTS, Components and AOP: While AOP has been proposed as a mechanism to adapt components, few AOP systems support non-invasive change to components. When non-invasive change is supported, non-standard extension to VMs is a common approach.

The implications of this for practical software development are significant: it is doubtful that component vendors could support components altered by aspects, and likewise, runtime vendors would be hard-pressed to support VMs extended for AOP. The investment to build an AOP-aware VM from the ground up seems unlikely, given the immaturity of the AOP model.

Security, versioning and other runtime concerns: Many AOP systems use a source of bytecode level weaver that inlines advice code at relevant join points. This complicates the configuration of security and versioning.

For example, the .NET platform supports a declarative code-identity security model that allows permissions to be assigned to a code identity. However, the loss of locality brought on by AOP means it is difficult to determine exactly what permissions some particular code needs. The ability for developers to declaratively refuse, assert and demand permissions further complicates the process of inserting new behaviour.

The capability to sign code with a key in .NET is also complicated by AOP – even the slightest alteration to the bytecode of a module changes the identity of the module, which impacts the build and deployment of modules.

Advanced platforms and languages address the same issues as AOP: New platforms and languages often raise the level of abstraction to allow greater programmer productivity. Advanced capabilities are often available outside of code: as configuration files, attributes, or stored somehow external to code.

For example, the .NET platform provides:

• Transactions: COM+, declarative transactions in .NET
• Synchronisation: COM+, language-level synchronisation primitives in Java and C#
• Marshalling: declarative marshalling instructions, and framework-level serialisation services

The concerns that become tangled within code have been identified by platform and tool vendors. While not all cross-cutting concerns are easily handled by generic platform mechanisms, a great many are handled to some extent.

Diminished locality: The ability of AOP to alter the behaviour of some oblivious code can decrease the ease of comprehension in some situations.

Encapsulation mechanisms like classes, procedures and inheritance also reduce locality. However, each of these are referenced explicitly in the module they effect – via an inherits clause, references to types and method calls. AOP takes a different approach, making “base” systems oblivious to their aspects.

This obliviousness is particularly problematic during the maintenance phase of software development. There is no AOP mechanism for flagging source code that has been aspected to ensure the impact of AOP is accounted for while a maintenance programmer attempts to understand a module. AOP could also be interpreted as directly opposing this kind of identification.

While this might be indicative of a true separation of concerns, it requires tool support to make maintenance practical.