Aspect-Oriented Programming Article On JavaWorld 75
Some Guy writes: "Javaworld has another article (the second in a series of three) on Aspect-Oriented Programming. Grady Booch wrote last year that AOP is one of three signs of a disruptive software technology in the horizon: a technology that could take us to the next level beyond object-oriented programming."
Booch's own company is hardly a poster child... (Score:4, Interesting)
However, working with Rational's software has tainted Booch's name for me. After dropping the large amount of cache for the entire suite, I think many people realized it would have been better to spend the month or so of man hours getting open source tool x, y, and z up and customized for bug tracking, requirements management, etc; rather than dropping tens of thousands of dollars and spending several months with Rational eating data and hoping the next emergency patch will fix our problems.
I'm well aware of the difficulties in developing large scale software, and I'm not suprised---I've worked on software that was done similar things
I was very impressed that the first edition of OOA&D had examples in CLOS, Smalltalk, C++, and Object Pascal (if I remember correctly). But I tend to think that when he publishes his next book it will be with examples in VBScript (probably on extending various MS Office products to interact with the Rational Suite, while alienating UNIX users).
Re:Booch's own company is hardly a poster child... (Score:3, Interesting)
Speaking as a professional software developer, I would have to agree. Rational Rose is the single most pathetic application I have ever seen, on a price vs. value evaluation. It is cumbersome to use and bug-ridden, it produces terrible output (all I want is a simple good-looking class diagram in UML; is that too much to ask?) and, most damning of all, it has manifestly failed to improve these flaws given years of time to do so. If this is an example of the benefits of Mr Booch's methodology, perhaps I'll stick to good ol' procedural programming after all.
Re:Booch's own company is hardly a poster child... (Score:2)
Re:Booch's own company is hardly a poster child... (Score:1)
-- Brian
Re:Booch's own company is hardly a poster child... (Score:1)
--
Re:Booch's own company is hardly a poster child... (Score:1)
Thanks for the tip about ClassBuilder. I've been looking for an alternative tool to draw decent UML diagrams for a long time, and you might just have shown me where to find it...
Re:Booch's own company is hardly a poster child... (Score:1, Informative)
Don't like it (Score:1)
Adding more keywords to Java (yes, Java programmers paid 20% better) without much reasoning (you can easily do the same things without new keywords). All ideas realized was sure met by language designers and was sure discarded for simplicity. Modulizing? Module structure cannot be defined by language itself unless language includes project management. Java don't.
Publishing you work in popular journal instead of specialized magazine. Word's like "higher productivity, improved quality" instead of clear evolution of new ideas. I don't like it. Point.
Re:Don't like it (Score:5, Insightful)
The difference is that when the concepts are supported in the languaes it is (a) orders of magnatude easier for the developer proficient in those skills to do it and (b) it allows for an order of magnitude more developers to grasp the concept and exploit it.
Java's EJBs are a current example of doing separation of concerns (SOC) without language bindings, in fact it it explicit in the original specification. The business rule writer doesn't need to know how the deployer deploys the EJBs and they don't need to know if it is an Oracle Database or DB2 or an IPlanet directory server serving as the persistance for the objects. As long as they follow an establised set of rules, such as business rules don't create thread objects and the deployer respects and stores all of the data that it is told to store it works. Then the person writing the business rules doesn't need to know about load balanceing and clusering and the deployer deploying into the load-balanced and clustered environment doesn't need to know a rats ass about the business rules or any other parts of the workflow for that EJB. Thus the people who do procurement rules procure and the people who know scaleability scale. In fact, the only time that the business rule guy and the deployment guy would need to talk is at the company christmas party, and they don't even need to know who they are.
Now we can look at how SOC is done in EJB and that is generally the same style OOP was done in C (not C++). There was a lot of infrastructure and practice that had to be followed that was not enforced or explcit, and the means of doing them were often different from project to project and even module to module within a project. When C++ came along it was much easier to establish how you denote inheretance for polymorphism and when a functon should be virtual and thus bound late. AOP languages like AspectJ are providing the means to provide for these "aspects" (I don't like the name either) much as C++ did for the OOP practicces. Making it more accessable and maintainable.
I must a gree with Booch, AOP will be affecting the future of software development as dramatically as the OOP concepts did. And if one doesn't keep up come 2010 you will be maintaining old payroll programs on a low paying contract rather than leading or managing a team on new software development in AOP.
Re:Don't like it (Score:1)
what you just described can be summarized in two buzzwords "Modularization" and "Encapsulation". Whats diffrent between an 'aspect' and an 'encapuslated method'? (I admit I haven't read the entire article yet, I will, I just came back to see if any comments could help me get through his buzzword soup)
Re:Don't like it (Score:2, Informative)
Hu?
The simplest aspect is a logging aspect:
,,on enter method``
System.out.println(method.name() + " entered");
,,on exit method``
System.out.println(method.name() + " left");
Now say:
,,all classes in package foo use aspect enter method and exit method``
A aspect weaver (somthing like an OO object code morpher) now injects the two aspects into all methods of the package foo.
Aspect oriented programming is about "grasping" ideas, code fragments, which are smaler than methods but can be regular expressed (like a regular expression).
Similar concerns are described in one aspect, its like a class consisting out of code fragments.
Then you write your classes without repetitive enter/exit -- or other -- patterns in their methods.
Finaly you weave classes and aspects together into an executeable.
There is a somewhat similar new way of programing: subject oriented programming.
See "hyperj" at ibm.aphaworks.com.
Regards,
angel'o'sphere
Re:Don't like it (Score:2)
But... (Score:2)
What he states as separation of concerns is good and all, but misses an important point-- clever modularization or a program and good design allow reasonable separation of concerns while still allowing the developer flexibility in how each module handles those concerns.
I don't like his description of AOP because I think that it takes good design principles too far and makes them inflexible. My experience with large applications has taught me that reusable code for common functions is very important, but so is control on how those functions are implimented in every case.
(And no, I am not generally an OO fan either because I think that in most instances, it makes the application more difficult to impliment, but there are HUGE exceptions to this, and I use it where I see fit. I often use proceedural programming on my core engines, structural programming where the data complexity becomes slightly higher, and OO when an abstract interface actually allows me to impliment extremely complex object models.)
Re:Don't like it (Score:4, Interesting)
AOP is not about Java but rather a total new way of modeling & programming (obviously the general idea was lost on you), it was just implemented on top of Java as a proof of concept. The people who implemented AspectJ (one of the handfull of aspect oriented languages), made sure that it works well, integrates nicely with the language.
Indeed, AspectJ evolved from just a prototype language a few years ago to a production ready compiler and toolset. The very reason it was created was to allow for industrial validation of the ideas that are behind it. The inventor of AOP (Gregor Kiczalez), figured that in order to do so you needed more than just a prototype language.
BTW. the journal side of things is taken care of by the ACM. They recently had a special issue of Communications of the ACM on AOP. Also nearly any conference on OO systems (e.g. Ecoop, OOPSLA, ICSE) in the past few years had papers on AOP issues (validation, language and compiler issues etc.).
If you want to learn about AOP, look at the tutorial and language spec on aspectj.org. Also be sure to look at the examples they provide.
Re:Don't like it (Score:2, Interesting)
Those kind of claims tick me off also. Why don't they simply say that this is a new way to do/look-at things that deserves further exploration.
To go barging around claiming that it will make everything cheaper-better-faster is disingenuine. It is waaaaaay premature for that. There are a lot of complex tradeoffs in software engineering. Improving one thing often can hamper others that promoters conveniently forget to mention/check.
I don't mind experiments, as long as they are labeled as such.
______________________
oop.ismad.com
I DONT INDESTAND TEH LANGUAGE DAT YUO SPAEK (Score:1)
The entire wildcard thing looks like it could really create some problems. Who knows what that will expand to? You certainly can't tell by glancing at the code.
re: wildcards (Score:1)
I imagine that it will end up like most of "one command does magic" coding ideas: the granularity is too large and there are too many exceptions to the rule to make it work in the real world.
Now:
*
2004:
* {unless x < 5}
2008:
* {unless case:
a: bar < 5 and foo
b: * > 9
c: * in (u,v,w)
}
2012:
* {unless class foo
method a {......}
method b {......}
method c {......}
}
Etc....
Gee, I don't sound too skeptical, do I?
Re: wildcards (Score:1)
Assuming I was not overrushed or outvoted in my technique, I find my code far easier to read than other people's code down the road. That is because I know how I think.
Software Engineering is *mostly* about psychology, and not math nor machines nor magic paradigms.
Re:I DONT INDESTAND TEH LANGUAGE DAT YUO SPAEK (Score:1)
Disruptive (Score:3, Interesting)
I think "disruptive" in this case means it may be another chance for gurus to promote their software and training as a solution to the problem that customers are dissatisfied with the "quality" of software, and software development schedules are too difficult to predict and control.
From "AOP" experts, I expect to see quite a few descriptions of obvious problems, and some hand waving "solutions", such as design/development "methodologies", "modeling languages", and "patterns", which are not as disruptive in the real world as they are in the academic papers and the product literature.
Re:Disruptive (Score:3, Insightful)
I call these things Hype-Oriented Programming.
OOP, AOP, Design Patterns, CASE tools, eXtreme Programming, yadda, yadda, yadda. The problem is they are usually valuable and make significant contributions to the body of knowledge in CS and software engineering, but even the successful ones (OOP) never live up to the hype.
The solution is to stay informed and keep up with new ideas and techniques, but point your fingers and laugh at people who jump from trend to trend, often never getting around to producing anything!
(The worse is eXtreme Programming, but don't get me started; don't even get me started.)
I've got a great idea (Score:2, Troll)
Then, let's call it AOP and hope the old Modula-2 programmers don't notice.
Can someone explain exactly what is new about AOP?
Re:I've got a great idea (Score:5, Insightful)
You have your regular OO program. Only you don't do the usual thing of littering with duplicate functionality for e.g. synchronization, persistance, security. This kind of code is what makes your program complex and generally requires rigid design rules in order not to blow up in your face. What AOP does instead is separate this kind functionality from your OO program into what is called an aspect.
Aspects consist of code and a pattern defining where this code is to be inserted in the OO program. This process is referred to as weaving.
Take for example logging. All large projects need this. Imagine you could just write down: for all public set methods in package X Y and Z: prior to execution write the name of the method that is called to the log. In aspectJ you'd define this functionality in a few lines of code whereas in your average OO language you would need to edit each and every public set method. In addition if you'd add a new public set method somewhere you would need to add the functionality manually. You might forget, introduce bugs (well, maybe not in logging).
Now logging is just the most simple example of an aspect. There are many more and the people at aspectj.org do a much job of explaining it than I can. So, go have a look with an open mind. Download the compiler, try the examples and use your imagination.
Re:I've got a great idea (Score:1)
that sounds like you end up with a very limited set of potential applications using AOP, either that or there is a very small set of 'patterns'? hmmm
ok last post before reading, closing
Re:I've got a great idea (Score:2)
Re:I've got a great idea (Score:2, Interesting)
I'm not entirley 100% convinced its really worth *that* much, every example he gave for OOP leading to bad design, well, was *bad design*; so I think I'll have to see a bit more realisitic comparison before I jump on the bandwagon.
I think a better description would be Event Wraped Objects, it seems more realisitic (though perhaps less easy to market).
Anyway, this is an interesting peice of trivia to have, I don't think its a end of the world type upgrade, but if it does catch on it should take alot less time to beat into my head than OOP did, considering all it appears to be is event wrappers for program actions.
but maybe Re:I've got a great idea (Score:1)
but then, if you had that sort of a system, there are a number of patterns that would do most of what you want - does AOP look like the retrofitting an event paradigm onto a more workflow type collaboration of objects?
AOP is a reinvention of multi-dispatch functions. (Score:1, Flamebait)
Funny how so many new programming fads are simply reinventions of old Lisp features because the new programming environments (like C++ or Java) need clumsy workarounds.
Re:AOP is a reinvention of multi-dispatch function (Score:1)
Re:AOP is a reinvention of multi-dispatch function (Score:5, Informative)
Kiczalez realized that if he'd stick to lisp, AOP would never work because ordinary C++/Java programmers would never be able to understand it (just like they never grasped meta programming, reflection and whole bunch of other advanced language concepts). Hence he made an implementation of AOP based on Java. One of the design goals was interoperability with Java so that the transition would be as easy as possible.
Now the difference between the visitor pattern and AOP is that the visitor pattern affects the design of your program (i.e. the places where visitors are used must explicitly call a visitor) whereas the usage of aspects is transparent.
Re:AOP is a reinvention of multi-dispatch function (Score:2)
Syntax easthetics is of course matter of taste but many would argue lisp is quite insane with all its parenthesis. The Java language was cleverly designed to look like C++ and be as clean as Pascal. Perl on the other hand evolved from a simple scripting language to an everything and the kitchen sink language. During its evolution nobody bothered to pay attention to the syntax (other than to stay as close to the more or less quick & dirty syntax of the earlier versions of perl).
I would say that being able to do something in lisp and practice of doing something in a certain way in lisp are two different things. AOP can be implemented rather easily on top of lisp but I don't know of many projects where lisp was used in an AOP style of programming.
Which is all well and good (Score:2)
To make it work better, something has to be done to reduce the power of the mechanism. Say, preventing the "apsects" from having any having any side-effects that affect the code that triggers them.
Re:I've got a great idea (Score:1)
Let me just comment on the basic motivation and goals of AOP. For more background I would refer people to the Aspectj.org website. You can also check aosd.net, where you will find the proceedings of more than ten workshops on AOP, and the larger goals of AOSD (aspect-oriented software development).
The basic goal has to do with separation of concerns at the design and code levels. Or, put another way, making the code look like the design. We all know how it feels to write good clean OO code. Each class represents a single tight concept, the methods within the class are similarly clear. The code is easy to understand and maintain.
We also know what it feels like to write messy, un-modular code. Things are scattered around, and its hard to change some things because they are not "in one place".
The idea behind AOP is that
-no matter how good your object (class) structure is,
-in decent size programs,
-there will be some design structures (concerns) that will be scattered around,
-because they naturally crosscut the class structure
(The idea is actually more general than OO, but I'm giving the more specific OO form of it here.)
AOP addresses that problem by providing constructs that explicitly support crosscutting structure in code. These constructs make it possible to say in one place things that would otherwise be spread around.
There's a nice example of this in the CACM paper, the ECOOP paper, and on aspectj.org. But let me repeat it briefly here.
Suppose you have a figures package, including Point, Line and other classes. Suppose you want to update the display whenever a figure moves. In straight Java, you would add a line like this to the end of any method that moves the objects:
Display.needsRepaint();
In AspectJ, we can write this in one place as something like:
aspect DisplayUpdating {
pointcut move():
call(void Point.setX(int)) ||
call(void Point.setY(int)) ||
call(void Line.setP1(Point)) ||
call(void Line.setP2(Point));
after() returning: move() {
Display.needsRepaint();
}
}
The key point being that the move declaration names "any time a figure
element moves", even though the code that does that is scattered
across two classes. We can say other kinds of things as well,
consider for example:
aspect PublicErrorLogging {
Log log = new Log();
pointcut publicCall():
call(public * com.xerox..*.*(..));
after() throwing (Error e): publicCall() {
log.write(e);
}
}
This says that whenever any public method in the com.xerox package returns throwing an Error, we should log the error.
I won't say more now. But I will note that there is something new here, even though it is based on bits and pieces of old ideas. You can't implement concerns like this with this degree of locality in straight Java. (Or CLOS for that matter!)
Re:I've got a great idea (Score:2)
Does the code that causes a class to utilize an aspect look something like this?
class foo using aspect PublicErrorLogging {
/* some methods here, all of which will be logged if they are called */
}
Thanks. Your comment has cleared the subject up immensely. I have found that a lot of new technologies are surrounded by a lot of fuzzy, impenetrable management speak. Just take a look at
Re:I've got a great idea (Score:1)
In this thread, someone else mentioned synchronization, persistance, and security. I'd have to learn more about how AOP is useful in these areas, but they do seem to cut across member boundaries, so I can understand how they'd make good targets. Your needsRepaint() example is another interesting one. (As a side question, would this fall apart if repaints weren't batched? I.e. if I changed an object's x and y and width and height, would that cause 4 screen repaints? Any way around this?)
So it seems like AOP is meant to solve the problem of "whenever we do X, we're going to have to remember to also do Y," where Y could be check security permissions, repaint, write to a log file, etc. Right? Can you suggest some example uses other than the ones already mentioned? I think this would help AOP overcome the one-trick-pony label in my mind.
lets play a game (Score:1)
software systems, concerns, crosscut, Object-oriented, concerns, invasive to implement, tough to understand, difficult to evolve, aspect-oriented programming (AOP), of crosscutting concerns, facilitates modularization, crosscutting concerns, easier to design, easier to understand, easier to maintain, higher productivity, improved quality, better ability to implement newer features
(done paragraph 1... this isn't looking promising)
"goal, concept, or area of interest" (to be fair that was a definition), core concern, system-level concerns, "transaction integrity, authentication, security, performance" (only because they were placed there to impress PHB's), crosscutting concerns, implementation modules, "systems that are harder to design, understand, implement, and evolve."
(end paragrph 2, slightly better, only half the words were buzzwords...)
separates concerns, modularization of crosscutting concerns.
ok, I think you have goten the point by now, attempting to finish the document.
If anyone knows something non-buzzwordish that has to do with AOP can you please post it? Since it appears to have stemed from Java and was never part of academia (a fact that kinda scares me), real factual sources are a bit lacking from google searches.
Re:lets play a game (Score:2)
Wrong wrong wrong. It did not stem from Java and the term was coined by Gregor Kiczales, who is a professor at the University of British Colombia. Arguably the first AOP system, composition filters, was invented at the University of Twente. There have been dozens of papers published by various groups from around the world, a bunch of AOP workshops and conferences, and there has been a Communications of the ACM Special Issue on Aspect-Oriented Programming. See aosd.net for links to conferences and papers.
--
Robin (who is doing his PhD on aspect-oriented programming and object databases, and will post more later).
Any better articles? (Score:1)
I dunno, but my mental buzzword filter kicks in reading articles like this. Or perhaps I am getting slow in my old age...
My main worry these days with new technologies is that many organisations and developers use them for namesake rather than practicality - they create a vicious circle where the job market becomes disproportionately biased in favour of technologies that are used less often but considered to be "important". EJB & XML spring to mind here - not that they are necessarily bad technologies, just that they are often over-applied just as a point-scoring exercise. And in many companies (not mine), employees are effectively rewarded for spending their time at work reading up on new technologies so that they can b.s. about them... generally leading to a bad work ethic centred around buzzwords rather than objectivity. Not that it bothers me, they are welcome to their inefficiency!
So, any links to more informative sites would be helpful, particularly one describing how it can improve productivity, quality, decrease development costs, or indeed, if it does not and why.... so far I am curious but unimpressed!
Re:Any better articles? (Score:2)
Here's what I get from it, translated into English, and sprinkled with some object-oriented terms.
Start with some Java code. This thing lets you search through the classes for method calls. For example, you could search for methods whose name begins with "Draw". Using these tools, I can attach event handlers to every call to these methods. My event handlers can run before and after each method call.
An "Aspect" is like a class, except it has really confusing syntax. The Aspect tells the compiler which methods to look for and what events to attach to them. Besides methods, it can also look for things like constructors or property setters.
An "Aspect" can do some nifty things. For example, if a class B inherits from C, it tweak it so B inherits from D instead. Also, it can add things (methods, variables, etc.) to a class or interface. Or it could change what kind of exception a method throws.
Then he talks about a few more advanced things, like how many instances of an "Aspect" I create. It could be static so only one instance exists, or I could make a new instance for every method I attach to. Or something in between. Also, an "Aspect" can show warnings and errors at compile-time.
Event system with makeup? (Score:2, Interesting)
MSDN has an article on AOP, as well (Score:2, Informative)
this month's MSDN has an article [microsoft.com]
about AOP as applicable to COM/COM+/.NET.
Re:MSDN has an article on AOP, as well (Score:1)
Jon.
Maybe I dont get it yet (Score:1)
With AOP you dont write the network optimization into every module, the computer does it for you. You just create a line of code that says "apply the network traffic optimization to all of the objects." While it is transparent to the programmer the develoment tool does in fact add the code then compiles it.
This is just one example. Can anyone confirm/deny this? If this is right I can see how it would save time and reduce confusion, making it very useful but it sounds like a lot of excitement over a small improvement to OOP. More like OOP++ than a new methodology.
Let me restate so folks can adress my comments properly
1)AOP seems not to change the final product before compilation. It does add a step before compile time, which is called weaving. Weaving seems to add required code to ensure that all aspects of each object are addressed properly.
2)AOP simplifies design and coding by placing the calls to the appropriate procedures or methods in the called procedure or method
***EXAMPLE*** (please excuse my pseudocode, my pascal is showing)
FUNCTION validate_input
{
ADD_THIS_FUNCTION_TO (object1,object2,object3);
}
FUNCTION object1
{//gets numbers}
FUNCTION object2
{//gets strings}
FUNCTION object3
{//gets passwords}
My understanding is that before going to the compiler AOP would process the code and weave in the FUNCTION validate_input simply by adding the code in the right places in oblect1, object2, and object3. a)Am I right? b)if not (if, for instance, aspectJ does something different which is more customized to AOP) would this have a similar effect?
While this example is truncated and perhaps illegible I would appreciate any feedback as to whether or not it is on the right track.
More food for the mill.
Re:Maybe I dont get it yet (Score:3, Informative)
Currently the compiler merely does some preprocessing and then uses the Java compiler but the long term plans are to create a separate, incremental compiler (to improve performance on large projects).
It is also worth pointing out that there's a difference between AOP and AspectJ. AspectJ is one of the many aspect oriented languages. Other examples include IBM's HyperJ and Karl Lieberherr's Demeter Java (do a search on google if you are interested).
AspecJ happens to do most of the weaving statically but this it could just as well do it at run-time. The only problem with that is that this would affect performance since you need to do all sorts of reflective stuff in order to make it work.
The best way of describing what AOP does is to think of your OO system as a graph of objects calling each other. Aspects insert functionality on the paths in this graph that augment e.g. return values or exceptions or introduce new data.
You could for instance insert an aspect that would simply count all accesses of public methods (not particularly useful but the point is that you can). In order to that you would need a static aspect (i.e. all insertion points get the same aspect instance) with an integer and some increment functionality. In addition you would write a pointcut (i.e. a pattern identifying insertion points in the graph) that gives you all the public methods. The AspectJ compiler does the rest.
The whole point of AOP is that counting the public method accesses is a concern that is different from the other functionality in your program. More importantly, in a regular OO program it is a crosscutting concern since you would need to insert functionality in each public method to make it work.
By making it an aspect you separate the concern from the other concerns that your program addresses. Should you for example discover that you would need a long rather than an int, you only have to update the aspect rather than each public method in your program.
Well designed OO programs also exhibit some separation of concerns. Typically you will find stuff like design patterns being used to do so. The price you pay is a more complex design. AOP potentially offers you a cleaner and easier to maintain solution than design patterns. However case studies will need to proof this (this is the primary motivation for creating AspectJ).
Re:Maybe I dont get it yet (Score:1)
I totally concur with that and would like to add a few sentences here.
Regardless of whether you like it or not, it is, imho, not anywhere near correct to talk about Java and AspectJ in one sentence. Of course, AspectJ applies aspects to Java code and generates code that is written in Java, but the basic capability to write in AspectJ requires the user to learn completely new structures which look like a language extension, but when you look at the way i.e. the pointcuts are defined, it's a new language.
Regardless of whether that is good or not, I think it needs to be understood.
It is also worth pointing out that there's a difference between AOP and AspectJ. AspectJ is one of the many aspect oriented languages. Other examples include IBM's HyperJ and Karl Lieberherr's Demeter Java (do a search on google if you are interested).
Thank you for pointing that out. it's a fact often forgotten. The term for all these technologies which is now widely used is AOSD (the Hyper/J people used MDSOC, for Multi-dimensional deparation of concerns).
Well designed OO programs also exhibit some separation of concerns. Typically you will find stuff like design patterns being used to do so.
I would like to add to that as well. Peri Tarr et al. have named that the "Tyranny of the dominant decomposition". That means that for every given module of software, you have one major decomposition, by class.
If you have accounting software, you have a class called "Account" and a class "transferal". There is, normally, no class first class entity which encalsulates the UI for the "Account" class, or its logging or any of the other tasks the "Account" class has to perform in addition to being the representation of an account.
That brings us to your next paragraph...
The price you pay is a more complex design.
The trouble with normal OO design is that, no matter how dilligent you design, how much patterns you use, how many factories and facade objects you use, there still remain concerns which have not been encapsulated or new concerns will be added which have not been anticipated.
These concerns become cross-cutting concerns which can not be implemented completely in one separate artifact.
That's the moment your application starts to get difficult to maintain and evolve.
AOP potentially offers you a cleaner and easier to maintain solution than design patterns.
Imho, AOSD is an addition to patterns. There are patterns which can be removed through use of AOSD technologies (see http://www.research.ibm.com/sop/sopcpats.htm for examples).
I hope that did add some informative tidbits...
Why I don't like AOP (Score:1)
I'm by no means an expert at AOP, I've never used it, only read about it. But from what I understand I don't think it's that great.
AOP seems most similar to the OOP approach of 'composition', that is, creating larger, more feature-full objects out of smaller sets of objects. I don't see any other fundamental difference between AOP and composition. If there is please enlighten me.
The problem I have with AOP (and regular OOP Composition doesn't fare much better in this regard) is that designing a system with a number of small distinct components seems like a good idea. It still seems like a good idea when you use composition to create larger objects with more functionality out of the smaller pieces. The point where AOP breaks down is when you want to use the AOP objects in some even larger AOP creation. The point when software development gets to this stage is usually well into the implementation and maybe after it is in production. At this point it seems to me like you're back to dealing with all the original problems that AOP was meant to help with (spaghetti-like code being the most significant).
Is there really more to AOP than what I've been able to deduce?
Re:Why I don't like AOP (Score:1)
Well, there is no panacea. If you have spaghetti code, you need to refactor, and AOP can help untangle code which talks about a lot of different concerns (more so than OOP can). If you can't refactor (because you're using third-party fixed APIs, or because it would be too expensive), tough.
Re:Why I don't like AOP (Score:1)
AspectJ violates locality guarantees (Score:3, Interesting)
With stock Java, you can inspect a particular method and know almost exactly what it does. It's a lot of work; you have to examine:
- the instructions inside the method
- the arguments to the method
- the instance variables and the methods of the containing class
- the instance variables and methods of the parent classes
- the contracts of any classes you have to be using
It's annoying to do but the lexical structure of the language makes it clear where you have to look. The only exception is when derived classes override methods in the class you're examining. (And this is a problem with every class-based OO language out there.) If the method is "abstract", though, at least you have some indication to look elsewhere.AspectJ messes this up badly, because you can no longer tell what's going on by tracing code. To understand the behavior of a method, you have to do everything you did before, plus know and understand every single Aspect defined for your program, since any of them may change any of:
- The behavior at the beginning or end of your method
- The behavior at any function call in your method
- The parent of the class
Aspect weaving is useful---it makes up for some of the lack of power of Java---but if Grady Booch's hype machine is successful, he'll sell a lot of books, people will use a lot of Aspects, and no one will be able to tell what is going on in their programs.Re:AspectJ violates locality guarantees (Score:2)
But that is just my guess.
Re:AspectJ violates locality guarantees (Score:1)
Re:AspectJ violates locality guarantees (Score:1)
Let's call the original functionality F, the guard functionality G and the sum functionality H.
The most common approach has always been to take F and bury it under an API. You can then mix G throughout, without any other code being aware. Any changes to the guarded code are thus localized and easier to modify, but the up-front effort can be annoying.
The standard idiom for functional languages is to make G a function that takes a function as an argument. Calling H passes F to G. G does the setup work, calls F, does teardown work and returns F's value. Scheme's call-with-input-file is a good example of this. The changes necessary to turn F into H are smaller, and F and G are much more cleanly separated. And it's clear what's going on in the code.
I think the best way of approaching Aspects is to compare them to operator overloading: if you're programming in a domain where it's a natural technique, it's wonderful (that was my experience doing 3-D graphics in C++); if you're using it for averything else, you're probably going to confuse the next person looking at your code. I think Aspects are a natural technique for any sort of instrumenting.
It would be amusing to survey the AOP/AspectJ boosters on what they think of operator overloading.
First read so what, 2nd read - maybe... (Score:1)
This has to be a joke, right ? (Score:2)
Well, apparently, this is exactly what a supposed expert on design is now suggesting. Code that executes on arbitrary conditions. Stuff that executes before and after your methods that changes their results. I can only conclude, given that Booch is clearly not joking, that this is a conspiracy to lower the quality of software and thereby drive more poor benighted, deluded souls into the arms of the Ration Unified Straightjacket and mechanistic OO design methodologies.