Talk:Aspect-oriented programming
From Wikipedia, the free encyclopedia
[edit] Comparison to other programming paradigms
Designers have considered alternative ways to achieve separation of code, such as C#'s partial types, but such approaches lack a quantification mechanism that allows reaching several join points of the code with one declarative statement.
- Could someone please elaborate on how the 'partial' capability of C# could be used to achieve aspect-oriented effects? I'm not quite seeing it. All the partial keyword allows is for you to define a single class in n parts (and possibly n different files). How does this even approximate aspect-oriented programming?
Isn't CL/CLOS Aspect oriented because of Multimethods and method wrappers
Methinks AOP should be related to the concepts of a database trigger and event-driven programming. I don't see that connection being made in the current article text. By the way, there is a Google Techtalk from May 2006 with Gregor Kiczales titled Aspect Oriented Programming: Radical Research in Modularity --LA2 20:08, 4 July 2007 (UTC)
[edit] extension of the motivation example
I would suggest that somebody who knows AOP extend the example from the section "Motivation and basic concepts" to show what it might look like in AOP.
- I totally agree. It would have been a great help for me also.ori
06:07, 11 September 2006 (UTC)
-
- I agree too. This is something that the article MUST have.
We must do some new section on disccution to poll about this subject? Maybe there is a reason for doing this but I think it must be done.
The article on Karl Lieberherr claims he introduced aspect-oriented programming. Maybe someone here could consolidate the two articles? Rvollmert 07:12, 2004 Aug 23 (UTC)
This is gibberish. Each piece of jargon is defined in terms of some other piece of jargon, never in plain English (or even in the jargon of object-oriented programming, which at least many people have heard of). 24.91.137.214 2004-11-28
This is a comment from the perspective of someone who doesn't know AOP, and is trying to learn a bit. First, thank you to the person who added the link to the "Attempt to explain AOP without buzzwords." Perhaps the wikipedia article could take some cues from that source? Second, with regard to the invention of AOP, the article says only "no one remembers exactly when". That may be true, but some sort of indication would be nice for those who don't even know which decade is the right one.
Just a minor observation - my expirience is that telecommunications applications' core concern isn't routing calls - it's billing, really bad example here.
- I agree with most of these comments above that this description of AOP is too complicated, but, more importantly, fundamentally wrong. I believe that the article will have to be substantially rewritten to be correct. It would be my first article, so I may need some help. I have a good understanding of AOP, but I am just getting started with the Wikipedia. My major beef is that a concern is never properly defined and the relationship between crosscutting and non-crosscutting concerns is never explained. Many other beefs stem from this. --Andrew Eisenberg 20:51, 5 May 2005 (UTC)
I just want to clarify something: in the intro it is stated that "An aspect can alter the behavior of the base code", and that is, in my opinion error-inducing. In fact (and i'm talking about AspectJ here) an Aspect can advise itself or other aspects. This may be important, as it is a source of many doubts for those learning AOP. --Rui 5 July 2005 00:48 (UTC)
- This page talks about Aspect-Oriented Programming in general, not AspectJ (at least until section 4). In AspectJ, it's certainly possible for aspects to advise themselves. However, that's not a requirement for AOP languages. Hyper/J, for example, only has a static joinpoint model and the hypermodules cannot make changes to themselves.
- Conceptually, I think AOP is easiest to explain by keeping the base and aspect modules separate, although it is true that this rarely happens when coding using AOP. When writing the intro, I tried to keep the explanation simple, rather than complete. However, if you have any suggestions for the intro, please make the changes or put them in the talk section. --Andrew Eisenberg 7 July 2005 17:21 (UTC)
AspectJ comes tightly integrated with a powerful set of tools, called AJDT, which assist developers in the understanding of how aspects and base code interact.
Not to nitpick, but isn't it loosely integrated, but very well supported?
You're right. I actually don't like that section 4 at all. There is already another article on AspectJ. And neither that article, nor section 4 here are all that good. What should happen is that section 4 simply becomes a link to the aspectJ article and that other article is updated. Any takers??? :-)--Andrew Eisenberg 23:53, 23 October 2005 (UTC)
This article contains 2 examples of standard java code and 0 examples of AO code... most unuseful.
Could someone add a discussion of aspect-oriented vs higher-order programming? The "other programming paradigms" touches on it very briefly. It seems like AOP is a special case of higher-order functions. Is there something else to it?
Another JavaScript implementation:
Dojo (http://dojotoolkit.org, a toolkit I work on) has implemented full before, after, around, before-around, and after-around advice for JavaScript by way of the dojo.event.connect() API.
An article describing the API is at http://dojotoolkit.org/docs/dojo_event_system.html. Discussion of AOP concepts begins about halfway through.
Perhaps someone else would feel comfortable adding it to the list of JS AOP implementations?
[edit] Is this correct ?
"AspectJ has two JPMs: pointcuts and advice, and inter-type declarations. Other aspect languages have different JPMs." 2 or 3 ?
[edit] Removed talk-like text
The following text (from the end of "Motivation and basic concepts") does not read like an article - it reads more like a discussion. It simply does not belong there as it is, so I have removed it. If it is useful and informative, please integrate it properly. Hairy Dude 20:12, 16 April 2006 (UTC)
Analogies from a newbie:
The use of this on methods seems to be similar to overriding a method in a subclass, but:
- You can change multiple methods and/or classes in one definition;
- You don't need access to the constructor / factory method to instantiate subclasses -- the existing classes are modified.
The use of this on variables / fields appears to be able to convert a plain old Java field into something like a "property" in C#, which is an accessor / mutator pair with syntactic sugar to look like a variable in an lvalue or rvalue context.
I'm sure I'm missing much of it, but perhaps this makes it more accessible?
Actually, I would think a better analogy in the Object Oriented world is the Visitor pattern. A Visitor encapsulates a specific behavior that could be entirely unrelated to the object that it is visiting; but at the same time, being able to inject that unrelated behavior into a method of that object. One difference I see between the Visitor pattern and AOP is that the visited object needs to know the interface of the Visitor and will also need to explicitly call the Visitor’s method.
[edit] Removing Tutorials
Why someone removed an easy tutorial to AOP http://www.alnaja7.org/AOP.ppt ? It tooked someone days to do a simple tutoril , but some don't like others to benefit ? Alhoori 01:24, 21 May 2006 (UTC)
-
- Is wikipedia a personal thing , so that you people can't decide whether the topics/links can remain or no ? How can I make vote on that ? Alhoori 09:15, 21 May 2006 (UTC)
[edit] Multiple Inheritance
Would it be accurate to consider the desire for multiple inheritance to be a desire for aspect-orientation? That is, If I have a drawable class and a shape class, I might make a class that inherits both to create a "drawable shape". —Ben FrantzDale 17:27, 13 June 2006 (UTC)
[edit] Adding example
IP address 128.122.253.228 wrote
[It would be useful if these examples were concluded with a parallel example of the aspect-oriented solution to these cross-cutting problems in the same JAspect/Pseudo Java, so that readers some reference points as they read the descriptions below.]
under the "Motivation and basic concepts" header. I'm assuming that person simply didn't know about the talk pages, and so I removed the comment. However, I think question is still valid, although it was posted in the wronge place. It would be helpful--if possible--for somebody more knowledgable about AOP to post a solution to the problem raised. michaelb Talk to this user 15:29, 28 June 2006 (UTC)
[edit] sample code with AOP
The sample of transfer method shows clears where the problem is without AOP. Can someone provide an "after version" of the same method with AOP? Thanks.--Mongol 17:46, 1 August 2006 (UTC)
[edit] "Problems adopting" and weasel words
The hypothetical programmer in this section is a bit one-sided and I think the entire section should be rewritten. It also should probably be renamed "Criticisms of Aspect Oriented Programming", to go along with most other articles that use that naming. -- Davetron5000 17:50, 22 August 2006 (UTC)
[edit] Muddled Definition
The definition of AOP above the Contents break is muddled with concerns about AOP centric languages. The explanation dives into what are apparently language usage debates before the reader even understands what AOP is. Somewhat like getting into a C++/Java/C# debate when defining what Object Oriented programming is, I don't see why AspectJ and the like are even mentioned in the definition beyond "some languages built to support AOP are..." statements.
[edit] Something wrong with formating
This page (the actual article, and when editing the article), looks very odd in lynx. can't figure out why. (doesn't happen on other pages). user:Bawolff (I'm not logged in here) 05:48, 22 January 2007 (UTC)
[edit] AOP example?
The code has lost its elegance and simplicity because the various new concerns have become tangled with the basic functionality There should be an example of this program rewritten in a AOP language so we can see how AOP simplifies this kind of thing.
[edit] Proposed Example Application
-- Reacton on the text above by TjerkWol 17:43, 24 February 2007 (UTC)
Note that such a program much be large too see the advantages of AOP... Below is an example *program* without AOP in it:
[edit] Non AOP Program
abstract class TwoDShape {
int getX();
int getY();
double getArea();
}
abstract class Circel extends TwoDShape {
int getRadius();
}
class Line extends TwoDShape;
class Rectangle extends TwoDShape
class Square extends Rectangle
This is just a small program that does not work, but the object oriented structure is clear. The subclasses of TwoDShape should implement the methods. I did not do it here to safe time, and because it is not neccesary.
[edit] Logging Aspect
Now suppose you want to log each call to any getArea like this
double Circle.getArea() {
log("Get Area Called");
double area=PI * this.r * this.r;
log("Area of circle is: "+area);
return area;
}
If you want to do something like this for each getArea method of each subclass of TwoDShape you have a lot of work, and also code entaglement.. What if you have added logging for all your getArea methods and someone else adds its own subclass of TwoDShape and does not implement the logging? Then you have a problem..
I have a Syslog class (C++) that writes to the syslog by default, and all logging in my project is done through a Syslog object. It's the first object built at runtime, and generally the only one, but it doesn't have to be. Every object doesn't need to reference it, it just has to be available. If I want it to do something different, I extend the class and change or supplement the default behaviour. Works for me, not sure this is a good example. Tsingi (talk) 01:35, 24 April 2008 (UTC)
[edit] The AOP Solution
AOP deals with this problem by identify this as a seperare concern, or aspect: a logging aspect. Pseude code for a logging aspect:
aspect GetAreaLogging {
// this defines all our methods that much be advised by this aspect,
// it is called a joint point.
// This one means: All subclasses of TwoDShape where getArea is called
jointpoint getAreaJoinPoint() : execution(double TwoDShape+.getArea());
// below is the actual advice, it is just a anonymous method of the aspect
// only the special aspect-enabled-compiler weaves this code in the base code
double around() : getAreaJointPoint() {
log("getArea called");
double area=proceed();
log("The value of the area is: "+area);
return area;
}
}
Hope you get the point a bit now, i know it is not easy. See aspectj.org for more information.
[edit] Side Note
Note that logging is the typical example concern to introduce someone to AOP, much more advance applications with AOP are possible. Read literature and websites to know more.
TjerkWol 17:43, 24 February 2007 (UTC)
[edit] Other comparisons (that would be useful to me)
How does AOP compare to Python decorators? (All of the examples seem to be exactly what a decorator would be used for in Python.)
How does AOP compare to Lisp macros? (Python decorators seem like a subset of Lisp macros, and from the article, so does AOP.)
How does AOP compare to CLOS
- It would also be useful if someone could compare AOP to what you can do with XOTcl mixins and filters. Donal Fellows 22:36, 15 September 2007 (UTC)
[edit] Missing "throws"
In the section "Motivation and basic concepts" there is "throw e" , but e is of type Exception so the function should have "throws Exception" (because Exception is not subclass of RuntimeException).
[edit] Adoption risks section
does indeed need a lot of work. For starters, it doesn't cite any sources. Next to that, some of the issues raised in that section apply equally to non-AOP programs or, even, non-Java programs. For example, the following sentence:
"For example, consider the impact of injecting code to return true at the beginning of a password verification function that returns a boolean value."
can just as easily apply to C / C++ code, seeing that anyone can use a profiler (or whatever the name for such a type of program is) to examine the various function calls and whatnot and change the program flow, for example by turning a false to a true in a password verification function.
And besides, hacking into a program like this requires a person distributing a somewhat altered version of the program, seeing that I'm not sure if it's even possible for, say, a virus to alter a Java program while it's running.
It's not an AOP-specific problem, even - with the right tools, anyone can decompile a Java program, insert his own code, and recompile. Or, on a higher level, anyone can alter the memory of a JVM by using special tools. (the last statement is a guess by the way).
The section seems, in my opinion, awfully negative towards aspect-oriented programming, highlighting problems that occur in any form of programming, in any programming language. Also, the advantages don't seem to be weighed in the comparison. —Preceding unsigned comment added by 62.58.16.59 (talk) 15:34, 13 November 2007 (UTC)
- I suggest that this "adoption risks" section be removed, because it is factually inaccurate. Never mind how weasel-ish it is, it just isn't a part of reality. Jfm3 (talk) 22:11, 16 December 2007 (UTC)
