AOP: Aspect Oriented Programming

AOP goes like this: If it's not part of your core logic it's an aspect and should in some way be separated from your core algorithm.

In a more literal sense, Aspects are application infrastructure components, as a foundation is to a house, Aspects are to a software application. Now how does this differ from OOP?

The intention of Aspect Oriented Programming is two fold:

1. Separation of Concern: the separation and centralization of application logic in a non redundant fashion.
   


2. Cross Cutting: entanglement of application logic within a program resulting in scattering tangling or both.
   

"For instance, if writing an application for handling medical records, the bookkeeping and indexing of such records is a core concern, while logging a history of changes to the record database or user database, or an authentication system, would be cross-cutting concerns since they touch more parts of the program." - Wikipedia

Some of you may argue AOP is no more than another level of abstraction in OOP, and you'd be correct in saying that. I personally find the theory interesting, but the practice a bit defeatist. As a .Net developer, I'm sure I'd prefer using the built in .Net Roles & Members over AOP, but, heck, if I can make my code more readable I'm up for giving it a shot.

Here are some interesting articles which talk to AOP, and a simple AspectF implementation (which isn't real AOP) by the creator of pageflakes.com:

Aspect Oriented Programming Wikipedia

AspectF Fluent Way to Add Aspects for Cleaner Maintainable Code

AspectF Simple way to cache objects and collections for greater performance and scalability

What do you think about AOP?

Over and Out