“What’s this new ‘aspect-oriented’ thing I’ve been hearing so much about?” If you’ve been asking yourself this question, check out this sample chapter to learn about aspect-oriented programming and how it can enhance your projects.
Introduction to Aspect-Oriented Analysis and Design
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
I’m quite familiar w/ OO programming, and quite like it, but have never done any AOP.
I’ve done some quick reading, articles like this, in the past and found the concept to present itself as more complicated than need be…of course I could be wrong…maybe it’s the best thing since sliced bread.
I have however been seeing a lot of articles floating around the web about devs who find that it complicates more than it helps.
How well is this AOP concept being adopted? I don’t hear a roar of acceptance in the programming world just yet.
I’m inclined to agree.
The aim of AOP is to separate program code related to the main purposes of the application (its core concerns) from code related to secondary purposes (cross-cutting concerns). It moves code not related to solving the domain problem from the business logic into a separate module.
From a software architecture point of view, this is what any software planner does, all the time, regardless. I don’t see how a purpose-built framework like this will help clarity.
AOP frameworks have issues of their own, ones, arguably that AOP hints at trying to solve itself.
This aspect thing seems to be an admission that even in the most well intended OO system there is the tendency to have control & data “tangling” a modern form of the goto curse.
By page 3 they start to mention the issues of syncronizing, locks and so on and correctly point out that that “has the potential to be problematic”. Too right it has, but that exposess the whole issue that concurrent programming and OO are not in step with each other period. The OO people have layered poor concurrency layers based on old style lock models onto an already heavy OO framework. Both Java & C# are culprits although I have to study the recent Java 1.5 changes. Funny thing is that even in the 80’s ADA was heading in the right direction but was just a bit too heavy and inaccesible to the masses of new programmers.
As another OO+Par acqaintance has pointed out to me, that when concurrency & OO are combined, you end up letting other threads play with your privates the worst form of “tangling”, thats not right. Also the class model has no sense of liveness, its is not even a good model for how things really work in the real world except in a static snapshot kind of way. When I 1st learned C++ I was pretty darn excited about the possibilities of modelling HW systems, when I discovered Occam & CSP I realised I had been hoodwinked, I realised that only concurrency based on ideas similar to HW processes have any chance of working so I give up on this paper.
my 2 cents
Functional program is a paradigm that is not seen very much in actual applications and sold. I am not talking about your LISPs, I am talking ML and Haskell. Beautiful languages both of them. They force you to think in another paradigm. OCaml and SML even do imperative programming at the same time to get a view of both worlds. I would like to see something done for these to make it easy to make programs.
>How well is this AOP concept being adopted? I don’t hear a roar of acceptance in the programming world just yet.
Check out the Spring Framework.
One of the reasons why (pure, at least) functional languages are falling by the wayside is that they don’t do I/O type stuff well enough for the way we use computers nowadays. Haskell gets around this with something called monads, and I don’t get the impression that it was ever a problem in LISP, but it’s a definite problem in languages like Scheme. While I’ve never done AOP or worked on a project large enough to make it worth considering, my intuition is that the a similar problem (namely, storing any sort of global state is non-trivial) in functional languages makes them a bit of a non-solution.
Besides, just try and get most folks to get used to a world where use of variables is strongly discouraged, sometimes impossible. It takes some overhauling of how you think about solving problems.
nice name huh….Now requesting Eugenia to mod me down:-)
You seem to think that java concurrency sux and thus OO and concurency don’t mix & match.
The Actor based languages could prove you wrong, but you can even safely look at Oz to see that you can have good concurrency, CSP and OOP togheter.
The authors have “forgotten” to tell us this… “Have you the license to write aspect-oriented programming?”
Beware of Aspect-Oriented programming. It is patented .
See US patents 6,467,086 and 6,442,750 :
http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d…
http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d…
Damn you Xerox Corporation!!!
/On knees in rain with fists waving to the sky as the camera backs away upward looking down on me /
all of these techniques and tools are just pointless future proofing attempts that are no better than those we’ve seen in the last decade.
you cannot future proof your code, don’t bother trying.
the best advice is still:
write as little code as possible to solve the minimal problem as you see it today using the tools most appropriate tools for that domain. remember every char of code is a chance for new bugs. less code = easier code = less bugs. anyone who debates this last point is a clear novice.
if new requirements come up in the future, either refactor, extend or entirely rewrite your code.
oops, i just made a sacriligious statement – rewrite your code? yes. all the so-called big brains who go on ad nauseum about how their technique-du-jour routes around this radical solution typically end up rewriting anyway by time the third major requirements shift happens.
i will stick by that last statement – on average by time the third major requirements shift comes down the pike most good coders will just admit its time for a rewrite in order to stop supporting requirements that are no longer active. WE ALL DO IT, even if we don’t admit it. BEWARE coders who never admit to demanding a full rewrite of their own codebases over the long term.