“What’s keeping you from trying out AOP? Whether you think it’s only good for low-level functions like tracing and logging, worry that it’ll get in the way of unit testing, or would simply rather stick with the object-oriented alternatives, Ramnivas Laddad gives you good reason to reconsider. Follow along as this popular author and speaker digs beneath the surface of 15 myths that hinder the adoption of AOP.”
Here’s why:
1. AOP support isn’t built into any popular programming language today.
2. AOP seems to be basically Java-only, despite the fact that the technology is applicable to any programming language. In fact, it’s not even restricted to object oriented languages.
3 People don’t realise it relates to Aspect Oriented Programming, since the articles describing ‘AOP’ don’t go out of their way clarifying what it is and what it stands for.
There’s also AspectL for Common Lisp: http://common-lisp.net/project/closer/aspectl.html
Reason 2 is not entirely correct.
Sure, the only platforms (not languages, read below) that support AOP are built on Java. AspectJ, JBossAOP, AspectWerkz. But that doesn’t mean that e.g. AspectC++ or quite a large number of .Net aspect frameworks do not exist. They do. Even for Python, Ruby, Lisp, PHP… oh, my! According to this ( http://www.jroller.com/page/deep?entry=aop_fun_with_javascript ) even for Javascript!
Now then I agree with reason 1 as the main one to slow adoption. But maybe we should ask why is this so. Many AOP proponents do indeed present it as an addon, a feature that you can add to existing code, not as something to push for inclusion in the language.
I also see a third reason for slow adoption the fact that AOP (as any paradigm would) forces you to think in different ways, to approach problems in a new way. If you want, this new way may even be easier than what they know, but it’s new and they have to learn about it, learn how it works, how to think that way, how to use it.
Sure, but… good programmers don’t have a problem with that, do they?
Probably not, but ‘good programmers’ have only a tiny voice in the way things are done. To give you an example, just the day before yesterday I was approached byt this guy at work. This guy is at the lowest level of management. He’s the one… I mean that level is were the action is, they are the ones that decide on the technical solutions that we want, they decide which way to go. They’re the ones saying ‘oh, Struts is the thing for web presentation layers. We should do everything with Struts’.
But he is management, ok? So his knowledge about real technical stuff is *ahem* limited. So he approaches me asking to evaluate what a certain tool does. you could think that it is me then that the power resides at. But no. What he asks me is not what tools are good for our work or if a certain tool is good for our work.
What he asks is if this tool is good for a certain aspect (no pun intended) or task he has in mind. I don’t get to decide if what he wants is good or not.
Anyway, to make it short… He comes to me and asks if this certain tool is good for… ‘instantly converting a dozen or so C and C++ programmers with no web experience into web developers’. It’s one of those tools, you know, where you don’t have to learn any HTML, Javascript, CSS, whatever.
In my ingenuity I almost ask if it wouldn’t be better for the company to have people that do know what they’re doing instead of… stupid robots. But I don’t, I know the answer: Keeping these guys stupid is way cheaper. If the tool’s any good, they can put out a fair amount of work for a lot less than it would take to have them taught. For the tasks that they don’t know how to acomplish, well, you can have one or two people who do know and it’s still cheaper.
So the moral of this long, boring story is: Management doesn’t what complicated (or even just new) ways of thinking. They don’t even want programmers thinking! What they want is mostly a couple of guys taking decisions and an army of trained monkeys.
You didn’t mention all the many languages AOP was implemented for…
In fact Aspect Cocoa is neat, I think.
http://www.cocoadev.com/index.pl?AspectCocoaTutorial
I think you could build AOP libraries for dynamic languages like Ruby/Python/Perl/JavaScript too.
Fact #1: I don’t get ASP.
I keep reading about it. I just don’t get it. Cross-cutting? As far as I understand it, it’s adding functionality outside the class itself so that you don’t add coupling. Seems to me like it’s trying to fix OOP. I’m just guessing here, but it seems to me that maybe another language would be more appropriate and cleaner.