What can be achieved by using AOP (Aspect oriented programming):

10 Comments

• How about argument validation.
  

• "Aspect Oriented Programming" not Abstract. Transparent Persistence is one of my favorites.
  

• Yes, thank for the correction. actually I think that most of the 8 RM-ODP transparencies could be achieved using AOP.
  

• You can add almost any infrastucture needs.... caching... security....
  

• atually they did implement it; it's just not documented. Look into ContextBoundObject, IContributeObjectSink, IContextAttribute and IContextProperty.
  
  
  
  They will also exist in indigo in a more robust form known as 'behaviors'.
  
  
  
  Paul
  
  

• Paul ,
  
  
  
  I argued with him about implementation of light container.
  
  thanks for the information anyway!
  

• Isn't AOP just a re-hash of Meta Programming?
  
  
  
  Anything that AOP can do, you could do with Meta Classes and Meta Programming.
  

• 
  I would prefer if the question were "Why use AOP?". There are many discussions of "Can this or that be done with AOP?". But to make AOP compelling to developers, advocates need to show that AOP can do things that OOP can not reasonably do. I'm not sure I even buy the usual logging example. I think logging code is scattered heavily in OO programs mainly because developers give it a low priority, not because of inherent flaws in OOP.
  

• AOP can achieve anything which OOP was NOT designed to do. OOP was designed to vitualize the business interests of an application in relationship to domain knowledge and persistent or long term memory. For example a Pet Store application code/data business interest domain should only capture the business rules, account, and the customer data Pet Stores are interested in in order to make money. OOP does not virtualize the governances interests of application monitoring(logs/diagnosis...), PKI, other domain's interests, content management, task management, generic utilities, hardware or external interfaces.
  
  
  
  AOP covers governances, or mandate, or interests outside the applicaiton domain.
  
  Ex: a couple gets married, they know how to make and raise kids - that is their domain, and that is all that their code and data should have. The government has a governance to listen for state changes and events within these person classes/couple. The government interjects it's code into the couple to make sure that their taxable status get noted.
  
  
  
  Voila!
  

• 
  That is an excellent example. I would agree with you that the "Couple" code should contain only information about the domain of being married and having kids. I am a firm believer in having an independant set of domain classes that encapsulate and model the application domain. These should take a front and center role in the design of the application.
  
  
  
  Where I differ is in the statement that "OOP does not virtualize the governances interests". Anything, within or without of the application domain can be implemented with OOP, there is nothing in OOP that says it cannot be used to implement the "Government" in the previous example, whatever role it may have. OOP is not just for modeling the application domain, any software programming task can be completed using OOP. In good OOP, lots of things become objects that are not representations of domain constructs. Consider patterns such as Visitor, Command and Strategy.
  
  
  
  The strength of OOP is that it enables you (via polymorphism, composition, and encapsulation) to 1) minimize artificial dependencies within your code, and 2) minimize duplicate code. These are universal goals of all serious programmers, and are not limited to the application domain. I will grant that many programmers are unable to acheive both goals using OOP, but I haven't seen how AOP will help them.
  
  
  
  That's why I am posing the question "Why use AOP?"