Click here to Skip to main content
14,736,616 members
Articles » Development Lifecycle » Design and Architecture » General
Technical Blog
Posted 13 Jul 2011

Tagged as


8 bookmarked

Aspects to Object vs. Aspects to Class

Rate me:
Please Sign up or sign in to vote.
5.00/5 (3 votes)
18 Jul 2011CPOL
Discusses aspects to object and 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.


This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)


About the Author

Gary H Guo
United States United States
Object-oriented (OO) is about "classes" not "objects". But I truly believe that "objects" deserve more our attentions. If you agree, read more on... Dynamic Object Programming (DOP), Component-Based Object Extender (CBO Extender), AOP Container and Dynamic Decorator Pattern.

Mobile development is not just another type of front end. The real challenge is actually in the back end: How to present meaningful information in time to mobile users with exponentially increased data flooding around? Here is my first mobile solution: SmartBars - Barcode Reader, Price Comparison and Coupons.

Gary lives in southeast Michigan. My first programming language is FORTRAN. For the last a few years, I have primarily focused on .NET technologies with Mobile Development as my newest interest.

Comments and Discussions

-- There are no messages in this forum --