aspect and oop differences

David-Robinson · Newbie Joined: Oct 02, 2006 Posts: 2 Location: UK

Hi Gopi,
the first point to understand is that AOP sits on top of OOP - even if you do hard-core AOP coding, you are still working with classes and other OOP things. The second point is that OOP says you have to compose a class in one file (well, the class header anyway). AOP says you can compose it from any number of files. That's really the key difference between them. Of course, this lets you do a number of new and fun things, some of which are dull-but-useful, some of which are exciting-but-useful (and frowned upon by the puritans of the world) and some of which, as Adam pointed out, can be harmful.

I'd play down the significance of the latter though, because crazy people write crazy code and they'll do it no matter what language you give them. I can't think of a single language that doesn't have something "harmful" in it, and yet the world still turns and the sun still rises. Polymorphism can be "harmful". Handles can be "harmful". Inheritance can be "harmful". I've seen all of these cause big problems that were very hard to track down and fix, but would I ban the use of them? No way! Why should I give up programming power just to cater for the lowest common denominator? The Linux kernel works even though it makes extensive use of the goto statement, and Linus Torvalds put it wonderfully with:

"> However, I have always been taught, and have always believed that
> gotos are inherently evil. They are the creators of spaghetti code

No, you've been brainwashed by CS people who thought that Niklaus Wirth actually knew what he was talking about. He didn't. He doesn't have a clue." http://kerneltrap.org/node/553/2131

Perhaps the best reason to consider using AOP is the exciting-but-useful (and frowned upon by the puritans of the world) one....

Adam made a good point when he said "the designer of incrementer has CHOSEN to allow subclasses to change the implementation of changeable by using the virtual keyword".

Well that's just fantastic *if* the designer:
a) knows *everything* I could possibly want to do with his code
b) manages to code consistently with no bugs
c) actually remembers to build in the required hooks (callbacks, virtual functions, facades, whatever)
d) builds in enough hooks for me to use

If I ever encounter this, I'll let you know. In reality, you'll probably find some code that doesn't quite do what you want, and you'll find it just before a big deadline when the original author is not available to fix it for you. At this point the conceptual beauty of a pure OOP solution is probably not what you'll be caring about.

The cool thing about AOP is that it can let you fix the code without touching the original source. There are many reasons why you might not be able to change the original source - it's 3rd party code, it's part of your IP repository, it's used elsewhere and you don't want to mess up someone else's project, etc. Perhaps you don't *want* to change the original code - you are prototyping an idea or only you care about the change you are making.

It doesn't really matter *why* you want to do this. What matters is that you *can*. Rather than putting all of the power into the hands of the designer, AOP puts it back into the hands of the user [1]. It lets "you" decide when and how you use the code.

Check out http://www.verilab.com/downloads/sample_chapter_verilab_aop_cookbook.pdf for more info.

Cheers
David

[1] Well, it normally does. Despite what you'll hear from people who've never used the language, you *can* finalise a class in e (but perhaps not all AOP languages?), which means it can't be extend by anyone. However, you have to make a concious decision that you really don't want someone to change it later. In OOP, just forgetting to type "virtual" is enough.[/url]
_________________
--
David Robinson
Verification Consultant
Verilab
david.robinson@verilab.com

JL · Junior Joined: Mar 01, 2004 Posts: 6 Location: Austin, TX

Adam,