Aspects to Object vs. Aspects to Class

It is clear that aspects address system (non-functional) requirements while classes address business (functional) requirements. System requirements are runtime requirements when software executes and are best addressed at object level.

Unfortunately, for all these years, most of the AOP products/tools try to address aspects at class level at design time. That may explain why AOP is still not widely adopted. In my opinion, classes should only concern about business requirements. They should not concern about system requirements. System requirements should be addressed at object level when the objects of the classes are used.

Here is why. A class is only a template for a set of objects. When you design a class, often you do not know (or may never know) every situation in which its objects are used. Take logging (a system requirement, by the way) as an example. If you add the entering/exiting logging aspects to a method of class employee, every object created from the class will pump entering/exiting logs when executing the method. If your code just loops through a few employees, it is probably OK. If you have hundreds of thousands of employees, do you really want to log every entering/exiting in the loop? You just can't anticipate situations like this.

My point here is: it is too early to decide whether you need an aspect to your class when you design the class. Then, when is the right time to consider an aspect? The answer is when you use objects of the class. By the time you use an object of the class in your code, you know the exact situation in which the object is used. Then, you can decide whether an aspect is needed for the object. If yes, the Dynamic Decorator (or maybe other tools) can be used to attach aspects to the object on the spot.

Using the Dynamic Decorator, business requirements and system requirements can be addressed separately. You use OOP to design classes to satisfy the business requirements. Then, you use the Dynamic Decorator to attach aspects to objects as needed based on the system's runtime requirements.

I agree to Dino Esposito's comment in his article Aspect-Oriented Programming, Interception and Unity 2.0 while he describes the benefits of AOP: the main reason for such a limited adoption (of AOP) is essentially the lack of proper tools. More specifically, I would like to say that although there exist a number of AOP tools, it is still lack of tools to address aspects at the right time and at the right place.

The Dynamic Decorator may be one of the first serious tools to address aspects at object level. I foresee more tools will come to address aspects at object level in the near future for two reasons. First, the needs are there. Second, people may shift their focus onto solving the AOP problem at object level once they realize that aspects belong to objects at runtime not classes at design time.

More information on aspects to object can be found in the article Add Aspects to Object Using Dynamic Decorator.