AOP… Should I unlearn OOP?
https://stackoverflow.com/questions/1325385
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianQuestion
I have skimmed the online documentation, read the wiki entry, the posts and the blogs, but I'm still puzzled.
- What is, in a nutshell, Aspect Oriented Programming ?
- Is it simply better then Object Oriented Programming ? Should I unlearn OOP ?
- If not, how do I know when to use one or the other ? What are the main differences between the two ?
- Can I refact one into the other ?
I have always been an OO man and I want to know if I need to commit treason.
Seriously, I'm starting a new project soon and I want to make the right choices at the beginning.
Solution
What is, in a nutshell, Aspect Oriented Programming ?
In a nutshell, AOP is the ability to inject actions into the typical flow of another program, unobtrusively. It lets you capture class instantiations, method calls, assignments, etc.
Is it simply better then Object Oriented Programming ? Should I unlearn OOP ?
No, and no. It works together with any programming environment that supports it. (See above).
If not, how do I know when to use one or the other ? What are the main differences between the two ?
You use AOP, generally, when you want to implement some sort of actions on hundreds of classes, without manipulating the classes themselves. Typical examples are security (authorisation of the right to call the given method/class) or logging. In my experience, though, I don't use it for this. (I don't use it at all, honestly).
As above, the main difference doesn't really exist, as they aren't comparable. But, say you want to implement logging "normally", you just call the logger at appropriate points:
log.write("hello");
But with AOP, you may create an 'aspect' that attaches to each method call, and log 'Method b called'. The point is that in AOP you approach is more 'shotgun': you attach to everything, or just a small subset. Manually adding logging is generally better.
Can I refact one into the other ?
Not really relevant, see other answers. Again with security, you could swap to an AOP model from a typical OOP model this.IsAllowed() to something like if(callingMethod.HasAttribute(foo)){ allowed = true; }
Hope those answers are useful. Let me know if you want me to expand further.
OTHER TIPS
No, AOP complements OOP, rather than supplanting it. AOP and OOP provide different kinds of "glue" to help you combine behaviors. OOP, of course, lets you combine behavior through inheritance and composition, etc. AOP on the other hand lets you add behavior to address cross cutting concerns by intercepting point cuts where your new code runs before or after the chosen methods of the chosen classes.
Some common examples of cross cutting concerns are: security, logging, and transaction control. A bedrock principle of good design is coherence: ideally, a piece of code should do just one thing. So it muddies the water to add security code to data access classes, for example. AOP solves that particular problem by letting you add the behavior in an "Aspect" and then applying that aspect to all the classes that should have security controls.
AOP is different than OOP, completely different approaches to development.
Basically, if you have logging, authentication concerns, performance checking code, these will be the same, roughly, in various parts of the program, in different classes. So, you can write your application as you envision it, in Java, then when you need to add in these other types of code (crosscutting concerns) then you just inject them into the program, so that they can be compiled in, but when you look at the source code, you just see the business logic you need there.
As to when to use AOP or OOP, I would suggest you write the program, get it working, then when you have it functioning, look at removing code that doesn't actually have to do with the function, but serves some other purpose. For example, if you need to check that the input parameters are correct before using them, then use an aspect for that. If you have similar event handling, such as all exceptions thrown in the data access layer writes to a log file, then create an aspect for that.
As you remove these crosscutting concerns your code will get smaller.
As you get more experience you will see more uses for AOP, but initially I would suggest write it, then refactor using AOP.
Use Eclipse, if using Java, for AOP, as the AJDT plugin will be very useful to see where you are adding aspects.
Aspect-Oriented Programming is a catchy buzzword for inserting actions (called "advice") into methods or functions at key points like calls and returns, among others. I have a big problem with AOP because it violates all the abstraction barriers built into the language. There's no way for a module to say "this is what an aspect can mess with and this is what an aspect can't mess with." As a result, you risk violating internal invariants, and you destroy the principle of modular reasoning (you can understand a module without having to understand anything but the interfaces of the other modules it imports).
Some years ago Raymie Stata wrote a brilliant doctoral dissertation about how object-oriented languages might control subclassing and prevent it from violating key invariants. The corresponding work for AOP has yet to be written.
While as with any other idea that gains currency, AOP has enjoyed a few spectacular successes (e.g., retrofitting logging to an application not designed with logging in mind), on the whole I would urge you to confine your use of AOP to very simple cases. Or better yet, just say no to aspect-oriented programming.
