 |
AOP - a poor man's excuse for writing ugly code
Posted by kirillcool on January 14, 2005 at 04:26 AM | Comments (21)
Let's take two examples that are given in any AOP language, logging and context passing.
AOP takes pride of the fact that it allows "injecting" code at the
beginning and at the end of any method (specified using sophisticated
"regular expressions"). But does this really qualify as a logging and
tracing mechanism? Not really. Any non-academic application has
functions with multiple exit points (although this on itself can be
called a bad programming practice) with multi-branch logics inside.
Typically I would have 5-8 log points with various log levels. The
important lines that i wish to log most certainly lie inside the code.
Each line prints information on specific objects. Moreover, these
messages must be localized using DB (or configuration XML file) and
filtered based on the log level that can change at runtime (presumably after an erroneous behaviour is spotted). AspectJ most certainly does not provide any means to do this.
Second, context passing. Now we have a stack of 10 functions and we
need to pass additional parameter to the innermost function. Now we
have two cases: there are already way too many parameters and we don't
want to pass an additional one (this is called not modular in AspectJ
tutorial); or we have some class that contains all the arguments and we
are too lazy to change it.
The second case is obvious - it costs next to nothing to put an
additional member to this class without breaking the modularity. The
first one is more tricky. If you have already 15-20 parameters for each
function, than your coding practices really suck. If you are unwilling
to add a parameter to a function that doesn't really need it, but has
to pass it to another function that does, you should rethink the design
of your functions. In any case, "pushing" a parameter into a code that
wasn't designed to handle it is very bad design. Moreover, this forces
reading multiple files in order to understand what each function does.
Another examples of AspectJ from the tutorial in short:
-
pre and post conditions - should really be a part of the methods
(especially in Java where you should be able to read the Javadocs to
understand what is the contract and when the exceptions are thrown)
-
contract enforcement - covering up for a bad design.
-
configuration management - via standard resource bundles, property files and Ant configuration.
Bookmark blog post:  del.icio.us  Digg  DZone  Furl  Reddit
Comments
Comments are listed in date ascending order (oldest first) | Post Comment
-
It took me quite a while to formulate my opinion on AOP. On the one hand, the tool used in one way allows you to advise virtually any method in your system. While potentially powerful for adapting or correcting modules to which we don't have the source code, in my mind, rampant use of this mechanism still qualifies as hacking at your code... It really wouldn't be good design, in my opinion, to design your OO system to require AOP advice at many levels.
However, on the other hand, I think that it does have its usefulness. Take the spring interceptor patterns, for example. When it comes down to it, this is just like subclassing or creating delegate classes. It just does it dynamically, and then, it only does it at the well-defined junction points in the system (where one bean depends on another). You could code all of these delegates yourself, or you could use a systematic mechanism to tell the container how to do it.
Like tool, I think that it can be abused. It can temporarily help sloppy programmers out of a jam, but it can also be used to help good programmers create better programs.
Posted by: tlaurenzo on January 14, 2005 at 07:49 AM
-
Thank you. I agree most with two of your points:
aspects will be useful when their behavior could be efficiently managed (not only "changed") at runtime
there is no common understanding of acceptable practices using this tool (there's too much freedom in applying AOP features)
I'm hopeful these two two issues are complimentary. Resolving the first issue should, in my opinion, reduce number of AOP features acceptable.
Another concern, Java could be not well suited for such ideal system. An ideal AOP system may work best with a language that has namespace that can be queried more efficiently than using regexps.
Denis.
Posted by: denka on January 14, 2005 at 08:50 AM
-
I originally jumped on the AOP bandwagon, but soon realized that the only reason to need AOP is to combat mistakes made in OO implementation.
Ego Tripping at the Gates of Hell
Posted by: jhook on January 15, 2005 at 11:05 AM
-
I agree that in most cases AOP could result in even bigger mess than usual ;-) But in the controlled envornment, like Spring container already mentioned, AOP can be used to gently introduce orthogonal, not-related concerns to your Spring beans. For example, in the project I am currently working on, the biz logic is implemeted in Spring beans and I have LoggingInterceptor, ExceptionProcessingInterceptor, SessionValidatingInterceptor, AccessControlInterceptor, etc wrapped around them. Looks much better comparing to all this piled up on top of biz logic.
Posted by: mgarber on January 17, 2005 at 10:21 AM
-
You do not understand AOP. Negative, uninformed, deliberately inflammatory posts like this do the community a disservice.
Posted by: crazybob on January 17, 2005 at 01:09 PM
-
bob, hadn't you blogged about your distaste for Struts and aspects of the EJB spec?
I don't get why people can't have a discussion about AOP without retorting, "you don't understand it". What is it that everyone isn't understanding? Why are we so misinformed?
Posted by: jhook on January 17, 2005 at 03:17 PM
-
I'm watching AOP from a distance with an uneasy feeling that mostly stems from AOP being completely opaque when you look at the code with unaided eyes - that is, an IDE which is able to show where code has been inserted via AOP. Otherwise plain looking at a method will not tell you at all what will really happen when the thing is executed.
Posted by: ctreber on January 17, 2005 at 11:25 PM
-
One of the most important things to me as a programmer is to be able to look at the code in any editor (not just IDE) and understand what the function does. The code should be easier to read than to write. Most of the AOP examples are very cryptic. If i look at somebody else's code in Notepad, i want to be sure that i'm not missing anything that will be byte-weaved at runtime.
Posted by: kirillcool on January 17, 2005 at 11:52 PM
-
As AOP originates from lisp,CLOS perhaps a quick look there can help some people.
http://www.gigamonkeys.com/book/object-reorientation-generic-functions.html
gives an introduction about how they work in lisp.
Posted by: fredriksvensson on January 18, 2005 at 02:01 AM
-
Kirill, if one of the most important things for you is to be able to understand code that is plainly in front of you just with Notepad (come on....), you should probably stick to procedural programming, or having one class with all the code needed for a certain job.
Furthermore, you should stay away from all kinds of code that utilizes external configuration, like EJB, Spring, Hibernate ...
If your tool preferences doesn't match designing applications in an AOP manner, that doesn't mean it's a poor man's excuse for writing bad code. It means it wouldn't work for you, based on your requirements and ideas.
Considering the above, do you assume everything new is a silver bullit? AOP works fine for some (who understand it well enough, and has decent enough tool support), and not for some. If it doesn't work for you, the only (constructive) reason to bitch about it would be if you wanted it to change/improve into something you could use. From what I've heard so far, that's practically impossible.
Posted by: miffel on January 18, 2005 at 03:52 AM
-
ctreber, ever tried AJDT? If you use the AspectJ framework it might be able to do what you're looking for. When I tried out AspectJ with Netbeans in 2002, it had some support for discovering what aspect code was affecting other code. I can imagine it has improved since...
Posted by: miffel on January 18, 2005 at 03:57 AM
-
miffel,
Looking at a function and understanding what it does has nothing to do with procedural programming. Even if the function is overriden, you have the exact knowledge of what it does (when called on this particular class). If it calls other functions, you see it clearly in the source code.
Giving Notepad was just an example. Of course i program in Eclipse and in IntelliJ, but sometimes when i need to see JDK code, i just open the correponding Java source in notepad to give it a quick look (without opening the whole IDE).
I can't quite understand the notion of pro-AOP community to quickly dismiss the opponents voices as "not understanding". It's not that we are new to the field. It may well be that we come burdened and biased with prior techniques (as well was the case of functional paradigm towards object-oriented programming). And it's not that i don't get the benefits of looking at aspects as horizontal behaviour definitions. One of my strongest objections is that when an aspect can affect all the code that is running and may interfere with other aspects, the stability and predictability of system behaviour deteriorates very quickly. It may be easy for you to write, but it will prove an AOP hell to debug and fix in a few months for another developer.
Posted by: kirillcool on January 18, 2005 at 06:18 AM
-
I wrote a response to this blog, mock track back:
When Will We Come Full Circle?
Posted by: jhook on January 18, 2005 at 07:11 AM
-
kirill, basically then what you have a problem with is not AOP, but using AOP in the wrong way (lack of best practices and experience?), and if you think AOP code will be hard to debug, you have a problem with AOP tools.
I still don't understand how your general title "AOP - a poor man's excuse for writing ugly code" should not be considered as "not understanding", considering that what you've written is a critique of 1) An AOP framework 2) How coders may use AOP (lack of patterns, best practices, examples or whatever) 3) AOP examples that some people most likely wrote to demonstrate ideas to get you thinking yourself, not provide you with silverbullet, ready-to-run in production code. AOP != AOP Tools. Please don't mislead your readers with such headlines, unless you're prepared to be challenged as "not understanding".
Posted by: miffel on January 18, 2005 at 07:34 AM
-
jhook,
you've already gone head to head with the guy who created the concept AOP (although there were several research team doing similar work at the time, like at the university of Twente) here (that was you, right?): http://www.theserverside.com/news/thread.tss?thread_id=30154#147658
(I especially liked Gregor's comment "That's what I believe, based on my experience with aspects." Heh. :-)
Why didn't you just take the chance to ask him what you wanted to know about AOP? He was trying to tell you, from what I could read. It's no sect, and it's not very hard to get the idea of it if you do some reading, some experiments and talk to people who know. If you did, maybe you'd understand better why people react to this FUD.
Sure, AOP can become a mess, misused, and mess up your hairdo in ways you never dreamed of. It can also work just fine, if you know what you're doing. And there are lots of different approaches AOP. Some bad, some good. Just because Kirill did something he thought was bad doesn't necessarily mean AOP is the problem. It's like blaming OOP when you've written some bad plain old Java code, atleast to me.
What I'm basically saying with all this, if you want to blame something, place blame where it really belongs.
Posted by: miffel on January 18, 2005 at 08:16 AM
-
miffel, yeah, that was me on theserverside.com (I didn't realize who he was, which probably actually helped open the conversation more) :-)
Pertaining to placing blame, I did reference that in my last post-- that possibly developers are just compounding issues for themselves because they didn't tackle OOP appropriately, then they seek out AOP or some scripting language only to compound more problems for themselves.
Posted by: jhook on January 18, 2005 at 09:24 AM
-
:-)
Sometimes, I guess that could be the case. In some cases, I don't think so. YMMV. I know of several people (including myself) who have found value in the AOP way of thinking. Some may not (of which some may actually have some AOP ideas built into their style of design, but that's a whole different story). We can agree to disagree there.
What I was referring to about placing blame though, was the entry above. The headline blames AOP itself. The contents basically blames AspectJ framework and tutorials. AOP != AspectJ. AspectJ is a framework.
If you want to blame programmers involved in AOP for not knowing OO enough, it seems like assuming a lot though. ;-) Or, we have a definitions disagreement here and nothing else. How do you define AOP?
Posted by: miffel on January 18, 2005 at 10:13 AM
-
I think of AOP in very generic terms, a way of encapsulating concerns in a horizontal attribute model instead of a vertical object model (if that makes any sense). Although I do have stronger issues with byte code manipulation and weaving, I'm very excited about annotations and metadata.
Posted by: jhook on January 18, 2005 at 10:39 AM
-
miffel,
The title of the entry was not meant to be a general opinion on AOP. What i meant was that AOP actually (at least in my view) encourages bad programming practices providing very easy means to plug almost any code at almost any point with almost zero effort. The result is (at least in my view) that the amount of work put into design will be minimal (XP), the code will change on the fly to accomodate ever-changing needs (XP), the code will document itself, or at least this is how aspects are shown to work (XP).
Not that i have anything against XP...
Posted by: kirillcool on January 18, 2005 at 11:25 AM
-
Ok, then I understand better. I don't agree however. :-)
Read the first paper on AOP (at least, the first I know that coined the term) from 1997 by Gregor et al; "Aspect-Oriented Programming". You'll see these kind of lines in abundance "design decisions have been hard to implement", "cleanly capture design decisions" etc.. It's obvious that many people have interpreted AOP quite different from me, but for me it's not about "hacking already existing OOP code", it's using a whole new thinking when designing systems (I'm not talking about full, upfront design here either, I found it never works for me in practice).
Many people apply AOPish thinking with pure OOP, but may sometimes find that they have problems getting everything in place. AOP thinking, with proper frameworks and tools, can make such situations easier, and help component reuse, assuming you've thought it through before starting hacking.
Sure, you have the opportunity for rapid change, and patching things on the fly, but when doing it you should still be thinking about your overall design, or you may end up in trouble. That holds when refactoring both OOP and AOP systems. The code will document itself? Hm, I never heard that somewhere... Sounds (without knowing exactly what you mean) like a tool/methodology problem.
Posted by: miffel on January 18, 2005 at 01:30 PM
-
One of the most important things to me as a programmer is to be able to look at the code in any editor (not just IDE) and understand what the function does.
Okay, then AOP is not for you. And neither is using listeners, at least beyond the basic ActionListener and WindowListener. As soon as you have several listeners registered to the same object, particularly one that listens for changes, not only for basic mouse interactions, it gets messy. You don't automatically know which files to open with Notepad. You will probably want to use an IDE in whose debugger you can examine the several threads running, pause and resume them seperately and so on.
For someone for whom looking at code with a plain-text editor is "one of the most important things" AOP would certainly be hindering. This does not make AOP a poor man's excuse for writing bad code.
Most of the AOP examples are very cryptic.
That's what I thought too - before I learned the AspectJ language, which only needed a few hours.
If I look at somebody else's code in Notepad, I want to be sure that I'm not missing anything that will be byte-weaved at runtime.
There are runtime AOP solutions, but AspectJ is a compile-time solution.
Posted by: monika_krug on January 19, 2005 at 04:52 AM
|
java.net RSS Feeds
