Beta

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Aspect-Oriented Programming with AspectJ

timothy posted more than 11 years ago | from the orient-your-object-aspect-please dept.

Java 496

Verity Stob writes "There is a turning point in the emergence of a programming methodology. It doesn't matter how big and popular the website is, nor how many papers have been published in the ACM journals or development magazines, nor even whether the first conferences have been a sell-out. A methodology hasn't made really made it until somebody has published a Proper Book. With Aspect-Oriented Programming with AspectJ author Ivan Kiselev is bidding to drag AOP into the mainstream. He is motivated, he says in his introduction, by the recollection of the 25 odd years it took for the object-oriented concept to spread from its Simula origins in frosty Norway to being the everyday tool of Joe Coder. He aims to prevent this delay happening to AOP." Read on for Verity Stob's review of Kiselev's book.

He has divided the book into four parts. Part I provides a brief sketch of AOP and introduces its concepts. AOP builds on OOP, asserting that we need a new programming entity called, wait for it, an aspect. Mr Kiselev's explanation of aspects reminded me of that bit in The Hitchhiker's Guide to the Galaxy when the planet Golgafrincham divided its population into A types (who were the leaders, the scientists and the great artists), the C types (who were the people who did all the actual making of things and doing of things), and the B types, who comprised everybody left over: telephone sanitizers, advertising account executives and hairdressers. As I understand Mr Kiselev, the AOP view of things is that objects and classes (A type thinkers) and low-level procedures and APIs (C type doers) can be nicely encapsulated using traditional components. But aspects, software's little hairdressers, get their fingers into everything, and until now there has been no way to encapsulate them. This of course is what AOP in general and specifically the AspectJ superset of the Java language set out to do.

AspectJ's eponymous aspects are constructs not unlike ordinary classes. Mr Kiselev has not resisted the temptation to make an aspect Hello World example, and it looks reassuringly so-whatish:

package intro;

import java.io.*;

public aspect HelloWorldA
{
public static void main(String args[])
{
System.out.println(Hello, world!);
}
}

Mr Kiselev then lays out his stall of New Things. A join point is any point in execution flow that AspectJ can identify and -- to get slightly ahead of ourselves -- execute some extra code. The most frequently used kind of join point being the call to a method. Pointcuts specify collections of join points; as a regular expression is to an instance of matched text, so a pointcut is to a matching join point. An advice (with horrid plural 'advices') is the code to be executed when a given pointcut is matched. If you are familiar with Eiffel's pre- and post-conditions, then you'll understand if I say that it is common for advices to run in the same way, topping and/or tailing the execution of a method. The differences are that aspects are specified from outside the method without touching the method or its class's code, and that aspects can be applied to multiple methods in one go. Mr Kiselev concludes this section of the book with a few simplistic examples of 'here is class A, here is class B' kind.

In Part II Mr Kiselev rolls up his sleeves and takes us through an extended, realistic example. I did wonder if perhaps it weren't a wee bit too realistic, as it is a miniature website application for news story submission and reading -- sort of Slashdot Ultralite -- all done using JSP and a MySQL database. Just explaining this setup, without even using any AspectJ, consumes a 15-page chapter. Since I am a C++ programmer who has not had any contact with JSP, I was initially anxious that I might not be able to follow this. However, recalling that www.[name withheld].com, the clumsiest, ugliest corporate website on the Internet, is programmed in JSP, I reasoned that if the dolts that programmed that site could understand JSP then it couldn't be very hard. So it proved.

The first example comprises adding password protection to the application. This is achieved by adding an advice that intercepts calls to doStartTag() methods. The advice can test if the user is logged in and, if he isn't, throw an exception that will dump him back at the login page. (Who says exceptions aren't 21st century gotos?) At this point Mr Kiselev admits that the cute 10-line implementation that he initially shows is in reality a non-starter; for one thing not all pages that must be secured define doStartTag() methods, for another the aspect can't reach an instance variable it needs to read because it is declared in protected scope. The second problem is easily overcome. AOP offers a mechanism by which extra classes can be bodged ('introduced' is the preferred verb in the AOP community) into the hierarchy as parents of existing classes. He uses this to add an accessor method for the field in question. The other problem is not so neatly smothered, and it is somewhat ruefully that Mr Kiselev produces his final, two-page solution. But I think that it is greatly to Mr K's credit that he does this - it tastes like programming in the real world as I have experienced it.

For the rest of Part II, Mr K demonstrates other applications of AOP using the AspectNews code. This includes Eiffelish design-by-contract stuff, improved exception handling, various debugging and tuning techniques (specifically logging, tracing and profiling) and a chapter on runtime improvements - stream buffering, database connection pooling and result caching - which show the AOP way to do things, usually where I would expect to be putting in proxy classes.

In part III we get down and dirty with the AspectJ language. This is the part where the book explains the obscure stuff: how to make a pointcut that picks up object preinitialization, or make an advice that goes off only when you are exiting a method on the back of an exception. I skimmed this bit - I guess it will become vital when I start using AspectJ in earnest. It looked good and clear on a flick through. A brief part IV contains some patterns, to give one a start when engaging AspectJ in earnest. Apparently it is horribly easy to create infinitely recursive situations, so if you here a faint popping sound from your machine it will be the stack colliding with the heap. There are seven appendices, supplying such things as a summary of the API in AspectJ's packages and hints on obtaining and using the Open Source supplementary tools mentioned in the book (Tomcat JSP container, MySQL database and Ant make replacement). AspectJ itself, now escaped from Xerox PARC, can be downloaded from the Eclipse website.

Complaints? None really. Oh all right, here's a nitpicklette because it's you: at page 75 Mr Kiselev adopts the irritating Internet habit of writing 'loosing' when he means 'losing'. Note to publisher SAMS proofreaders: do I win 25 cents?

For the rest, this is a lucid and readable book that describes the Next Big Methodology. I'm a bit alarmed at the prospect of squeezing new actions into the cracks of existing code, but I dare say I'll grow to love it.

A word of warning to the eager: since this technology is currently implemented as a species of preprocessor that relies on having all the source code available at once, so it is rather slow and probably isn't going into production shops for a while. There again, I seem to remember the comparable Cfront C++ compiler doing rather well, before we had platform-native C++ compilers.

And to the sceptics: if you think you can ignore AOP, don't forget the fate of the A and C type inhabitants of Golgafrincham, who having sent their B type telephone sanitizers into exile were all wiped out by a germ caught from a particularly dirty telephone.


You can purchase Aspect-Oriented Programming with AspectJ from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

cancel ×

496 comments

Sorry! There are no comments related to the filter you selected.

Have to do it... (-1, Offtopic)

Angry White Guy (521337) | more than 11 years ago | (#5433271)

First Post

dang (-1, Offtopic)

Anonymous Coward | more than 11 years ago | (#5433276)

not fp... :(

So, what is this? (2, Interesting)

Juiblex (561985) | more than 11 years ago | (#5433293)

What is Aspect-Oriented Programming?? I've never heard of it!

Re:So, what is this? (-1, Flamebait)

Anonymous Coward | more than 11 years ago | (#5433331)

the gimmick dejour. yet another programming methodology that hopes (in vain) to eliminate the need for skilled programmers.

Re:So, what is this? (0, Flamebait)

punkball (240859) | more than 11 years ago | (#5433379)

Amen.

Re:So, what is this? (3, Insightful)

Ouroboro (10725) | more than 11 years ago | (#5433473)

What is Aspect-Oriented Programming?? I've never heard of it!

the gimmick dejour. yet another programming methodology that hopes (in vain) to eliminate the need for skilled programmers.

Once again someone proves the old saying Better to keep your mouth closed and be thought a fool than to open it and remove all doubt. I can see why the above response was submitted anonymously.

The goal of Aspect-Oriented programming is not to eliminate the need for skilled programmers. The goal is to reduce the local complexity of code. Make it so that when you look at code who's job is to store some data, it isn't cluttered with all of the other code like debugging and error handling. The point of this isn't to remove that code all together, but rather to make it much less tightly coupled. Why should persistence code be married to logging code? The answer is it shouldn't, they are two entirely different functions. Aspect-Oriented programming makes it easier to decouple them. This makes both pieces of code more flexible, and reusable.

Re:So, what is this? (1)

EnderWiggnz (39214) | more than 11 years ago | (#5433555)

its obvious that AOP will succeed where OOP, Top-Down Design, UML, and JAD failed.

its another stupid methodology that appdev shops will spend lots of money chasing.

bfd.

RTFA (0)

Anonymous Coward | more than 11 years ago | (#5433352)

And you might look less like a total dickhead.

Re:So, what is this? (3, Insightful)

ralico (446325) | more than 11 years ago | (#5433361)

I've never heard of it either, but I'm suspicious of things that claim to be The next big methodology.

From what the reviewer talked about with A types, B types and C types, it sounds a whole lot like roles and the delegation design pattern.
Agree? Disagree?

Re:So, what is this? (0)

zanerock (218113) | more than 11 years ago | (#5433407)

Design patterns themselves are just renaming something every skilled programmer already used, and now every unskilled programmer bandies about like so many Microssoft Certifications.

I'd say that logically, it's about the same thing, but the AOP model does have one thing going for it in that it provides actual tools instead of just a lot of talk. I don't see any sort of revolution here, but I think it's much more useful than patterns for that reason alone.

Re:So, what is this? (0)

Anonymous Coward | more than 11 years ago | (#5433454)

And, what, you think it's a bad thing that patterns allowed programmers to transfer good practice to other programmers?

You're not one of these silly elitists, are you?

Re:So, what is this? (5, Insightful)

Minna Kirai (624281) | more than 11 years ago | (#5433515)

I've read a few papers, but never managed to pay much attention. However I tried to put it in terms of how you might accomplish such effects with a traditional programming langauge.

Basically, imagine if you wrote a program which had "hooks" scattered through it. As you write your code, you place hooks for before/after doing many things: reading user input, transmitting network data, accessing preference files, checking permissions, etc. (Imagine wrapping all your function calls with dynamically-bound functions which you don't yet know if map to an identity function, or have some effect)

Other parts of the program can then hook into these things and effect how your program runs, without them having to go through and modify your code. (Example: if they want to log a message to file everytime your "CastRay()" function is called, they can do this without going in and editing your code).

Now, imagine than rather than the programming having to plan ahead to scatter hooks all around his code (uglifying it towards readers who don't care about them), they are inserted automatically by the compiler.

So a person can create a function which will be automatically called whenever some other set of 3 different functions is called, without having to go modify each one. Instead of going to each function body and adding a call, he at one position attaches his code to functions of that kind. The program is shorter, but has more effects. This may mean, when all goes well, that if someone adds a new function with similar effects, those hooks may still get called.

Now, is all this a code idea? It's hard to say, Aspect-Oriented programming (like OO programming) is yet another way for a program to do things without the source code making it abundantly clear. In OO, if you see one method A call method B, you must check the source code for all base classes to see if and how B was virtually overridden, a complexity that didn't exist before. Now, with AOP, you must be aware "is this behavior creating a context which will cause some Aspect to add in more effects"?

In both those cases, the program is doing things that the source code doesn't make 100% clear to a programmer reading a single function body. This can be either good or bad. The usage of editing tools which evaluate the code and alert the reader to these facts (analogous to "class browsers" in several IDEs) shift it much further towards "good".

Re:So, what is this? (5, Interesting)

Caoch93 (611965) | more than 11 years ago | (#5433616)

Now, is all this a code idea? It's hard to say, Aspect-Oriented programming (like OO programming) is yet another way for a program to do things without the source code making it abundantly clear. In OO, if you see one method A call method B, you must check the source code for all base classes to see if and how B was virtually overridden, a complexity that didn't exist before. Now, with AOP, you must be aware "is this behavior creating a context which will cause some Aspect to add in more effects"?

It's my opinion that, if you have to ask that question, then you and everyone else on your team are doing AOP in a bad way. The entire function of AOP is to separate disjoint concerns so that you don't think about them when you're programming. You write application logic. Your fellow team member maintains your security aspect. You don't ask "When I call this method, will it trigger the security aspect?". Especially in a world of runtime AOP, it's not possible for you to really have a reliable answer.

Long story short- if two separated concerns in AOP have such a sufficient dependency that you have to ask yourself a question like that, then they should not be separate concerns at all. At least, in my opinion.

Re:So, what is this? (3, Informative)

whazzy (620752) | more than 11 years ago | (#5433526)

Aspect-oriented programming (AOP) is a new language paradigm proposed for cleanly modularizing the crosscutting structure of concerns such as exception handling, synchronization, performance optimizations, and r esource sharing,that are usually difficult to express cleanly in source code using existing programming techniques. AOP can control such code tangling and make the underlying concerns more apparent, making programs easier to develop and maintain. In aspect-oriented programs, the basic program unit is an aspect. An aspect with its encapsulation of state with associated advice, introductions, and methods (operations) is a significantly different abstraction in comparison to the procedure units within procedural programs or class units within object-oriented programs. The inclusion of join points in an aspect further complicates the static and dynamic relations between aspects and classes My humble request:Please take a moment to use Google before you feel the urge to click the submit button here:-)\

Re:So, what is this? (5, Insightful)

tickleboy2 (548566) | more than 11 years ago | (#5433532)

Aspect Oriented programming is a brand new programming paradign, kinda of like the switch you made when going from functional programming to object oriented programming. It's a different way of expressing your programs

The reason that Aspect Oriented Programming was created was due to "cross-cutting" concerns that cannot be easily modelled in object oriented programming. I read the presentation for AspectJ and the example they used was logging in Apache Tomcat. Bascially the code that is used for logging is scattered throughout the whole program on hundreads of different lines, not all in one nice neat class. Aspect Oriented Programming wants to give the programmer the tools to gather all of this code together.

Bascially, Aspect Oriented Programming is supposed to result in: less tangled code (code that is fragmented throughout your program because you are unable to modularize it well), more natural code, shorter code, easier to maintain and evolve, and more reusability.

One question I had about the book that the review didn't seem to answer was did the book talk at all about designing using Aspect Oriented Programming? Just like Object Oriented Programming, it's a great tool until you get some inexperienced programmer who just knows how to program functionally, and thus doesn't use the advantages of aspect oriented programming. I too would like to learn more about how to go about designing a program in an Aspect Oriented way; such as how to identify aspects, what are some common aspects, etc.

In all, I'm very excited about Aspect Oriented programming. I think it has the ability to allow programming to shape thier programs more naturally, make their programs easier to understand, and make the whole process much eaiser. But of course as with any new technology, it has some growth and refinement to go through yet.

Those of you who would like more information can check out the AspectJ [eclipse.org] webpage, or the Aspect Oriented Software Design [aosd.net] webpage.

Smelly (-1, Offtopic)

Anonymous Coward | more than 11 years ago | (#5433296)

Joe Coder

Joke Odour

Hmm (-1, Troll)

Anonymous Coward | more than 11 years ago | (#5433298)

Perhaps if *BSD implements some of this code it will stand a chance? Perhaps it won't die after all?

Re:Hmm (-1, Offtopic)

Anonymous Coward | more than 11 years ago | (#5433324)

Good point. I hadn't considered that aspect.

Where's this useful? (1, Interesting)

KiahZero (610862) | more than 11 years ago | (#5433301)

I honestly don't understand the applications for this. Maybe it's just because I'm reading the review rather than the actual book, but it does'nt feel all that useful.

I can understand the benefits of OOP over standard top-down programming, but I'm failing to see where this coding methology gives you any gains.

Re:Where's this useful? (0)

Anonymous Coward | more than 11 years ago | (#5433314)

It's like Emacs hooks, except for Eclipse. Derrrr!

Re:Where's this useful? (-1, Troll)

Anonymous Coward | more than 11 years ago | (#5433347)

Asspick programming was used to create the linux kernel.

Oh, aspect. Dunno, that just seems like a new and unneeded buzzword.

Re:Where's this useful? (4, Informative)

Mahrin Skel (543633) | more than 11 years ago | (#5433374)

I can see it. Okay, you know how OOP lets you over-ride ancestor behaviour in descendants? But if you want to combine the behaviour of two different objects you have to either encapsulate one in the other, or go all the way back to their common ancestor and create a new descendent line because if you change the root line then *all* descendants are changed?

AOP would seem to let you over-ride methods or invoke special handling *without* touching the object directly. You simply tell the compiler "When this method is called, do this first (or afterwards)."

On the one hand, this could lead to spagetti code nightmares, since execution paths could become effectively untraceable. On the other, it's in many ways cleaner than putting your special-case or over-ride code directly into the methods and objects directly.

--Dave

Re:Where's this useful? (5, Insightful)

nojomofo (123944) | more than 11 years ago | (#5433461)

I'm not trying to troll here, but I'm afraid this might sound like it.... It sounds to me like the main selling points of AOP are that you don't have to design things well in the first place, because if you missed something, well then you can change how your objects behave without redesigning them.

The place where this wouldn't be true is with code that's part of the API or other code that comes packaged. I think that changing the behavior of this type of code sounds pretty dangerous to me - there's a reason that some data is kept in private and protected variables! Wouldn't you get into situations where you've added and aspect or a parent or some such thing, and in the process you access a private variable, and then you upgrade your runtime environment which changes the INTERNAL structure of the code that you hooked into (leaving the external API the same), breaking your code? Isn't that what code encapsulation is for? What I'm hearing touted as AOP's best feature is that you can break encapsulation.... Count me out.

Re:Where's this useful? (1)

tshak (173364) | more than 11 years ago | (#5433486)

You simply tell the compiler "When this method is called, do this first (or afterwards)."

Maybe I'm misunderstanding your point, but can't this be accomplished via OOP?

override MyMethod() {
// ...
base.MyMethod();
}

Re:Where's this useful? (1)

Minna Kirai (624281) | more than 11 years ago | (#5433539)

That only works in OOP if you actually are creating a derived class (and, depending on language, if the other programmer didn't make it a "final" method)

In AOP, you can decide to apply pre/post behaviors to a bunch of methods without needing to first create inherited classes, and then change the construction-calls ("new MyOverRiddenObject") to make those new classes.

Re:Where's this useful? (1)

kwerle (39371) | more than 11 years ago | (#5433599)

That only works in OOP if you actually are creating a derived class (and, depending on language, if the other programmer didn't make it a "final" method)

Or if you're writing in Obj-C. Using Obj-C, you can dynamically replace instance methods on the fly and call the previously defined method when you're done/before you start (or both, or not at all).

It's easy to do, and it's a dream if you need to patch a system, but it leads to code that is hard to debug/understand.

Re:Where's this useful? (0)

Anonymous Coward | more than 11 years ago | (#5433550)

This sounds about right. It's basically trying to abstract the cross-object interactions that are necessary for things like effective synchronization and transactional support.

This sounds good, but I'm skeptical about the market for this. On the server side these things are handled by management environments like servlet containers, EJB systems, and (shudder) .NET environments. On the client the need for these services isn't great enough to make supporting a new programming paradigm worthwhile. It could be useful on the back-end, but it will take a long time to catch on.

It's worth remembering that one of the reasons that OOP took so long to catch on was the lack of decent compilers for OO languages (particularly C++). Aspect proponents should take note.

Re:Where's this useful? (3, Insightful)

dima233 (148467) | more than 11 years ago | (#5433375)

Writing to a log before and after an event is an aspect. A logging facility could be coded as an aspect.

D

Re:Where's this useful? (2)

sergio.garcia (549229) | more than 11 years ago | (#5433445)

The sad thing is that the loggin facility is the only convincing example I have heard so far. :P

Re:Where's this useful? (2, Interesting)

Lord of the Fries (132154) | more than 11 years ago | (#5433384)

The common examples seem to be persistance, concurrency, and something else. AOP is OK, my problem though is that its applicability to orthogonal issues seems (to me) limited. I am rarely able to find any more uses than the common three examples. I am much more interested in some of the recent work done on Traits Programming.

Re:Where's this useful? (2, Interesting)

cushty (565359) | more than 11 years ago | (#5433460)

The other is probably design by contract or something like that. Checking that things that call a method pass good parameters and that methods return what they say they should. A generic aspect could check that all parameters are not null and that a method doesn't return null. A more specific aspect could check particular method parameters, return values, and object consistency. Once confirmed to be working you remove the aspects and your code will "just work like normal" *gulp*

Re:Where's this useful? (2, Insightful)

Ed Avis (5917) | more than 11 years ago | (#5433400)

'Advice' in Emacs Lisp is handy for running your own custom code before or after any existing function. So it's another way of adding hooks to existing code. A highly customizable app like Emacs is a natural place for this sort of language facility.

And of course, INTERCAL has the 'COME FROM' statement.

Re:Where's this useful? (5, Informative)

cushty (565359) | more than 11 years ago | (#5433408)

Aspects are cross-cutting concerns, they are things that cut through numbers of classes. My way of thinking: draw vertical rectangles side-by-side and call these "classes", now draw a horizontal box that cuts through them all and this is an "aspect".

The simple example, and one used in the book I believe, is that of logging. Say you have to log the entry to and exit from every single method in your code. Typically you would probably write this directly putting "entering XYZ, exitting XYZ" actually in the code. But with aspects you can write one aspect that basically says "on entry to any method log the method and parameters, on exit log the method" and compile your code and away you go.

So? Why would I want to do this? Well, now that you have been through your development process and discovered everything runs fine, you decide to go into production. Want to remove every single log line to improve speed? With the "normal" approach you'll have to write a script to remove them or do it manually. With aspects: just dont use the aspect in the compilation! Put them back in by compiling in the aspect again.

For me aspects are a real benefit but they do you head in for a while when you're an OO programmer!

Re:Where's this useful? (1)

stratjakt (596332) | more than 11 years ago | (#5433463)

So you're saying that aspects are helper functions or classes, that are implicitly called, rather than explicitly? (maybe implicit is the wrong word, but they're attached from outside the code itself)?

So this basically saves you the hassle of writing stuff like this?

#ifdef DEBUG
do this
#endif

Seems in a large project it would be real easy to forget about code that executes that you cant see.. Is the added complexity worth it?

Re:Where's this useful? (2, Interesting)

Minna Kirai (624281) | more than 11 years ago | (#5433583)

Seems in a large project it would be real easy to forget about code that executes that you cant see.

The nice thing, then, would be a smart editor which is aware of aspects, and can draw flags on top of the source code you're reading so that the programmer is warned that an Aspect will be sticking it's nose in.

Even better, you could click those flags to apparently expand the aspect's code inline, revealing exactly what statements will execute when the function runs. Of course, this can't be reliably done in all cases, if the Aspects are something that can be toggled on/off as the program runs.

In that case, the editor might have to be pessimistic, and assume "an Aspect might apply here...". But that might not work well either. In the end, you need smart programmers, both writing the aspects, and using them.

A few better examples (1)

rossjudson (97786) | more than 11 years ago | (#5433633)

Logging is an easy one for AOP. Here are some more interesting things you can do:

1. Security processing...weave security checks into your code.
2. Transaction monitoring.
3. Automatic event propagation (get rid of those nasty JavaBeans listeners).

If, in a given situation, you call several methods in order, and that pattern is repeated across many other methods, each of those calls is a candidate for AOP, where you weave the calls in directly through pattern matching, rather than typing.

It can result in dramatically reduced code. It also _enforces_ behaviors (like when you forget to add that one line that does the security check).

Without AOP you are programming by exceptions, not by rule.

Re:Where's this useful? (5, Informative)

Enonu (129798) | more than 11 years ago | (#5433505)

Yeah, this review didn't introduce AOP that well.

Going here:
http://dev.eclipse.org/viewcvs/indextech.cg i/~checkout~/aspectj-home/doc/progguide/index.html

I found this code example:

pointcut move(): call(void FigureElement.setXY(int,int)) ||
call(void Point.setX(int)) ||
call(void Point.setY(int)) ||
call(void Line.setP1(Point)) ||
call(void Line.setP2(Point));

and then this:

after(): move() {
System.out.println("A figure element moved.");
}

As you can see, "after" any method call as defined by the pointcut, System.out.println is executed to reflect this fact.

I can see how this would be great for logging, checking pre/post conditions, quicker debugging, or anything else that is of a "horizontal" nature in your code.

Re:Where's this useful? (2, Informative)

ndvaughan (576319) | more than 11 years ago | (#5433528)

I did a paper on AOP last semester. Basically, AOP not only gives you an object-oriented view of the code, but also splits it up according to other aspects of its functionality, like "security", or "debugging". Then, when you want to add a certain functionality to multiple objects, all you do is name all of the class methods that are affected (called a "joinpoint"), and then write one section of code, instead of changing each and every object (or class) that you would have to do if you were using an OO language. Go to http://www.parc.com/groups/csl/projects/aspectj/in dex.html [parc.com] and look at some of the PPT presentations. They describe it pretty well.

Re:Where's this useful? (3, Interesting)

Caoch93 (611965) | more than 11 years ago | (#5433533)

Really, the biggest use for AOP is, as far as I know, still not available in AspectJ. AspectJ was, as of the last time I looked at it, just an additional compiler for a language extension to Java. As a result, I can't say that I find AspectJ all that amazing.

AOP is a very interesting notion in that it allows you to separate your concerns. Application logic, security, logging, transaction maintenance, etc, etc, etc. All of these things can be written separately but are then woven together at specific critical points. The result of good AOP programming is that your code is cleaner, and the guy writing application logic thinks only about application logic, not about persistence, caching, security, etc, which are all implemented as separate conerns and woven together later.

The real power is the ability to define this at runtime instead of compile-time, though. Imagine this- you write a generic caching and persistence layer for an application. You write this once. Then, at runtime, any time you want to apply this persistence layer's functions to an object, you just instruct the application (through a config file or some other means) to weave the persistence layer in with a specific object. Boom. Instant persistence. You could do this with any feature really, as long as you wrote each aspect generically.

This is a pretty extreme boon for certain classes of applications. Specifically, take any application that's modular or componentized. Each component can now have additional services dynamically bound to it. You can apply code as a policy over any activity...field modifications, method calls, constructors...etc. As a result, you can apply special policies to modules or compnents in your application without having to actually code them in to the component.

Other possiblities include applying advice to the constructor of Thread objects that checks threads into a registry on their creation. Now, every thread in the VM has a handle in this registry. If a thread flies off into an infinite loop, you can see the stacktraces of all the threads easily and have a better point to investigate from.

It's worth noting that the applications that really will benefit from this methodology...applications servers...are taking note of it. The JBoss 3.x series was written with a limited form of AOP that can only apply policies in limited ways to objects that implement certain interfaces. The next major version of JBoss promises the opportunity to leverage runtime AOP so that any Java object can have server services bound to it regardless of whether it implements an EJB interface or not.

Again, though, the power comes in in the ability to make these pointcuts at runtime. AspectJ, as far as I know, still doesn't offer this, so you can't dynamically change the aspect policies in your application dynamically. That makes AspectJ pretty useless for AOP in my book.

Then again...I could be talking arse. Here come the flames!

Re:Where's this useful? (1)

BMazurek (137285) | more than 11 years ago | (#5433554)

When you decompose a system into a set of objects, you do so according to what some call the dominant decomposition. By virtue of consolidating various (I hesitate to use this word here in this context) aspects of your program into these object classes, various other aspects of your program get scattered to the wind. (This is called the tyranny of the dominant decomposition.)

AOP allows you to consolidate these portions of your program into a independent entities: aspects. An aspect will encapsulate a certain feature of your program into one location where you can easily modify, extend or replace it.

Wrote an application and would like to insert ACL checks for security prior to accessing data sources? Encapsulate this in an aspect. Maintain that aspect independently. If you want a version of your application with security, compile it with the security aspect included. Want a version without security, compile it without the security aspect.

Want to add security to another portion of your program? Where do you add it? Do you add it the security calls to the applicable methods of classes X, Y and Z? Or do you extend the set of join points to which your aspect is applicable? That is, do you add the security-layer calls all over hells-creation, or do you add it to the consolidated list recorded in your security aspect?

The more I look at AOP and the more I see, the more I think this will revolutionize development.

I prefer reading... (5, Funny)

borgdows (599861) | more than 11 years ago | (#5433311)

Microsoft-oriented development book at Microsoft Press!

This book contains every programming concepts and practices to avoid like hell!

Re:I prefer reading... (2, Insightful)

arvindn (542080) | more than 11 years ago | (#5433552)

That's truer than you think. For instance, take this "Code complete" book by some Microsoft guy. I went through the horror of being forced to read some chapters of it in college. It recommends monstrosities like "Hungarian encoding": the name of each variable should reflect 1) its data type 2) what type of variable it is ("counter", "array index", etc) 3) what its supposed to do 4) what you were thinking when you named it, and other things too numerous to list.

This is from /usr/src/linux/Documentation/CodingStyle

Encoding the type of a function into the name (so-called Hungarian notation) is brain damaged - the compiler knows the types anyway and can check those, and it only confuses the programmer. No wonder MicroSoft makes buggy programs.

An example (0)

Anonymous Coward | more than 11 years ago | (#5433622)

Re:I prefer reading... (2, Insightful)

namespan (225296) | more than 11 years ago | (#5433629)

Having types work their way into names isn't entirely brain damaged. The hungarian way may be -- I tried it for a while, and couldn't make it stick. However, some data types lend themselves to it. Ever notice how often file pointers have the name fptr? That's because the naming convention serves the programmer -- programmers have an abstract convention of a file pointer in their head, and they work with it. Similarly, every once in a while I'll find myself giving a name like "HostList" -- a list (linked list, perl list, doesn't matter) of hosts.

And Code Complete really isn't a bad book at all. It may give you some false starts and misdirections, but it will definitely make you think about aspects of software development methodology.

Re:I prefer reading... (1)

punkball (240859) | more than 11 years ago | (#5433556)

But its put out by Microsoft? I thought one of the coding practices to avoid was coding for Microsoft platforms?

Re:I prefer reading... (1, Insightful)

Anonymous Coward | more than 11 years ago | (#5433562)

Actually Microsoft Press books have a few gems like "Rapid Development" and "Code Complete" by Steve McConnell.

This just goes to prove that knowing how to do a good job and actually doing it are two completely different things.

Fascinating (4, Funny)

Limburgher (523006) | more than 11 years ago | (#5433325)

I love that aspects seems to provide alternative techniques without loosing any ease-of-use, coing-wise. I was afraid that in switching to this new method I'd loose some functionality, or maybe loose some speed, but so far so good. Nothing to loose any sleep over. :)P

Re:Fascinating (1)

jackjumper (307961) | more than 11 years ago | (#5433462)

I'm trying to decide if this is funny or if the person didn't actually read the review, in particular the part about the editing and 25 cents...

Re:Fascinating (2, Funny)

Pinky3 (22411) | more than 11 years ago | (#5433494)

I almost loost it when i read that someone modded this interesting instead of funny!

Yet another reason to switch to Lisp (5, Insightful)

Anonymous Coward | more than 11 years ago | (#5433354)

I should have stuck with Lisp all this time. When OO became hot, we could switch to OO without a preprocessor (early C++) or a whole new language (C++ or Java). (Eventually, Lisp got CLOS -- the first standard language to do OO, in fact.) If AOP gets hot, that'll just be a few more macros.

Once you've used a language like Lisp with closures, macros (at the language level, not wimpy C macros), and code-is-data, it's hard to go back. I feel sorry for everybody who has to use Java, for whatever reason, and will have to get a new language/compiler/libraries just to take advantage of a slight change in "what's hot today".

Re:Yet another reason to switch to Lisp (1)

mccalli (323026) | more than 11 years ago | (#5433433)

I should have stuck with Lisp all this time.

Never trust a language with more brackets than code...

Cheers,
Ian

Re:Yet another reason to switch to Lisp (3, Informative)

swagr (244747) | more than 11 years ago | (#5433485)

Take advantage of both languages.
Of course, as everyone knows, there are Scheme/Lisp implementetions in Java:
http://grunge.cs.tu-berlin.de/~tolk/vmlangu ages.ht ml
Ones that act as interpreters or compilers to Java byte code.
Or write your own (it's not that hard) http://www.paulgraham.com/rootsoflisp.html

Re:Yet another reason to switch to Lisp (1, Funny)

Anonymous Coward | more than 11 years ago | (#5433493)

((((((((((((((((((((((( I ((((((((((( absolutely ))))))))))) agree )))))))))))))))))))))))

Bad code (4, Funny)

Anonymous Coward | more than 11 years ago | (#5433357)

System.out.println(Hello, world!);

Where are the quotes?
I dont trust this guy if he cant write a HelloWorld app.

MOD PARENT UP +1 Pedantic! (0)

Anonymous Coward | more than 11 years ago | (#5433484)

What do you mean there is no such setting?

Re:Bad code (1)

diablobynight (646304) | more than 11 years ago | (#5433509)

lol compiler error line 4 I guess he just ignored it and went on writing his article about a book that reiterates information I heard 2 years ago.

So, what is it? (1)

Dixie_Flatline (5077) | more than 11 years ago | (#5433364)

I went to AOSD.net and the description there is a little thin. They say that there's a good overview in a particular issue of the ACM, but last I checked, you have to pay the ACM if you want to retrieve any articles online. Does anyone have a website that gives a solid overview of what AO is? A quick googling gives me a whole bunch of specific language pages or links back to AOSD.net.

Re:So, what is it? (2, Informative)

Halo1 (136547) | more than 11 years ago | (#5433517)

The original article that introduced it can be found here [nec.com] (download links for the article in several formats are at the top). Google also has a nice collection of links [google.com] .

What is Aspect Oriented? (1)

utahjazz (177190) | more than 11 years ago | (#5433366)

I'm not getting any instant gratification from the above links and blurb. Can someone explain in a few sentences what Aspect Oriented Programming is?

Re:What is Aspect Oriented? (2, Informative)

DamnStupidElf (649844) | more than 11 years ago | (#5433475)

It looks like the concept is to group common methods from many different classes into a form that can be acted on uniformly. The example they gave allows for the creation of several multi-layer classes, all related and built upon each other. A "join point" is constructed as a collection of all methods that actually create new objects. The article explained that this is particularly useful for security, since while there may be many different classes that can be created, a join point can be used to allow or disallow the creation of any or all of them in a single place. The advantage is that security code does not have to be maintained in each class independantly.

Re:What is Aspect Oriented? (2, Informative)

WeaponOfChoice (615003) | more than 11 years ago | (#5433541)

The advantage is that security code does not have to be maintained in each class independantly

This is precisely what I use AOP for. Whilst there is tremendous opportunity for spaghetti coding, so long as you adhere to some reasonable standard of layout and documentation it works out much more maintainable for certain design patterns.

Re:What is Aspect Oriented? (1)

jjohnson (62583) | more than 11 years ago | (#5433592)

In other words, interfaces and factories?

Mandatory karma whoring (-1, Offtopic)

Anonymous Coward | more than 11 years ago | (#5433367)

Kudos, my man. Kudos.

Sounds like pre-post "exception" handling (2, Insightful)

binaryDigit (557647) | more than 11 years ago | (#5433370)

Sounds a lot like adding a pre "exception" handler in c++, mixed with somewhat normal exception handling, and doing a Microsoft and making it declarative. Sounds like an interesting feature, but without reading the book and seeing what else there is, hardly anything earth shattering. Just another way to have the compiler/dev environment formalize a programming practice.

A methodology hasn't made really made it until somebody has published a Proper Book

Are they kidding. Hell there probably books out here on clipping your finger nails using a new methodology. Now days having a book don't mean squat (unless you're a tree, beaver, or a bird).

Re:Sounds like pre-post "exception" handling (0)

Anonymous Coward | more than 11 years ago | (#5433415)

It isn't limited to exception handling. You can do it anywhere. Why not read one of the many webpages out there and actually learn about it instead of guessing from a book review?

Re:Sounds like pre-post "exception" handling (1)

binaryDigit (557647) | more than 11 years ago | (#5433449)

It isn't limited to exception handling.

I know, that's why every time I say "exception", I placed it in quotes. I was relating the physical mechanism to something similar in C++.

Re:Sounds like pre-post "exception" handling (1)

binaryDigit (557647) | more than 11 years ago | (#5433471)

Oh and a better analogy sounds like the many 4gl's out there that provide pre-post handling for their forms. This concept is then extended to methods vs form objects.

Here we go again.. (0, Insightful)

Viol8 (599362) | more than 11 years ago | (#5433381)

Another obscure and pointless programming paradigm dreamed up by an academic who
wants to make a name for himself. God save us from the egos in the computer world...

Re:Here we go again.. (1)

Caoch93 (611965) | more than 11 years ago | (#5433634)

So, you've tried AOP before? Compile-time weaving or run-time weaving? Wasted your time? How?

AOP is a very useful perspective to take, though, and I've seen it used to some incredibly good ends. Rhetoric it cheap.

first post??????? (-1, Redundant)

Letter (634816) | more than 11 years ago | (#5433383)

am i am i am i am i am i????

so what (0)

Anonymous Coward | more than 11 years ago | (#5433386)

i took a class in aspect oriented programming. it was taught be a man who had taught and than worked with the developers of aspectJ (as grad students) and i still could not tell you how it is useful.

This is not good (2, Insightful)

DrunkBastard (652218) | more than 11 years ago | (#5433391)

Anyone else think that such concepts as this will lead to even more laziness in programming? Even more bloated and redundant code? Maybe I'm missing the whole concept, but this seems more of a "it's not working right so lets throw some sort of wrapper around it and see if that helps" attitude rather than "hrmm, perhaps I should tear apart that function, do some debugging, see if I can simplify what I'm doing, and reduce some overhead while I'm at it..."

Re:This is not good (1)

stratjakt (596332) | more than 11 years ago | (#5433530)

I agree, though I think it could make a tool for troubleshooting or debugging. Aspects that do the trivial example of logging, or sanity checks, make sure the system is stable before entering a critical routine, or what have you.

Object Oriented code can great if its well designed and layed out intuitively. If it isnt, it's endlessly more confusing than the most convoluted maze of gotos that ever crawled out of a TRS 80. AOP is no doubt the same.

Re:This is not good (2, Interesting)

Minna Kirai (624281) | more than 11 years ago | (#5433620)

"it's not working right so lets throw some sort of wrapper around it and see if that helps" attitude

This attitude is already pretty common. "Oh, we can't understand what this library does, so we'll write a transparent wrapper which instruments all function calls, so we can gain a clear picture of what's going on"

If AOP was used, then at least when a programmer decides he's got to throw a wrapper on something, he can do it with a few lines of code (define an aspect on the classname, using wildcards), rather than spending all day to copy & paste every single function in the class and add his 3 lines of "instrumentation".

And then when his foolish adventure is done, and the extra code is nothing more than a drag on performance, it can be removed (or just disabled) from a single place, rather than once again scrolling through all of a class's source code to touch each and every method.

Loosing vs Losing (0)

Anonymous Coward | more than 11 years ago | (#5433403)

I will never understand how anyone could get the idea that "loosing" is the gerund form of "to lose".

There is not a single conjugation of "to lose" that has double o's.

It may be wrong, but in my mind, a person loses a lot of credibility for such a mistake. The HelloWorld example, looks like an OOP approach anyway, this book looks like a complete waste.

Re:Loosing vs Losing (1)

PD (9577) | more than 11 years ago | (#5433538)

I thought Toulouse was a city in France.

To sum up (1, Insightful)

Joe the Lesser (533425) | more than 11 years ago | (#5433405)

Like objects, aspects may arise at any stage of the software lifecycle, including requirements specification, design, implementation, etc. Common examples of crosscutting aspects are design or architectural constraints, systemic properties or behaviors (e.g., logging and error recovery), and features.

Okay, so there are some objects that don't act like objects, so he wants to call them aspects and give them more power and scope throughout an application.

The main concern is while this may improve a program, I see 'aspects' being dropped in favor of meeting a deadline.

Eclipse Project makes AspectJ more mainstream (5, Informative)

mparaz (31980) | more than 11 years ago | (#5433406)

This letter [eclipse.org] announces that AspectJ [eclipse.org] is no longer at aspectj.org as it has moved to the Eclipse project [eclipse.org] .

I think this is a very good thing since Eclipse is one of the most popular Java development tools, and is concerned with good coding practices like refactoring and coding helpers. Plugins allow people to add their own stuff. With this, people who haven't heard of AspectJ or Aspect-oriented programming would take a look.

Interestingly, the Eclipse homepage does not explicitly mention Java. It says, "Eclipse is a kind of universal tool platform - an open extensible IDE for anything and nothing in particular." Personally, I have only used it for traditional Java. [kalixia.com]

Ha! (-1, Offtopic)

Anonymous Coward | more than 11 years ago | (#5433416)

Look at this crap. Computer "scientists" are so extremly losing... I'm glad I studied physics.

I have a bad feeling about this (1, Interesting)

Anonymous Coward | more than 11 years ago | (#5433418)

If you are familiar with Eiffel's pre- and post-conditions, then you'll understand if I say that it is common for advices to run in the same way, topping and/or tailing the execution of a method. The differences are that aspects are specified from outside the method without touching the method or its class's code, and that aspects can be applied to multiple methods in one go.

Sounds like a code maintenance nightmare if there ever was one. And I don't even want to think about all the "But I thought Joe put that safety check into the advice so I didn't worry about it in the main class" problems.

for more info (0)

Anonymous Coward | more than 11 years ago | (#5433419)

on aspect oriented programing and aspectJ check out http://www.ccs.neu.edu/research/demeter/DemeterJav a/ and http://www.ccs.neu.edu/home/lieber/LoD.html

if memory servers me right the author (or is it authors) of aspectJ were taught be the inventor of demeterJ

My 2 bits... (5, Insightful)

praetorian_x (610780) | more than 11 years ago | (#5433428)

Aspect oriented programming is moderately useful, though, if it isn't built into the language (and, in java, it isn't) it can be cumbersome to work with.

In java you can get 50% of the way to AOP using Dynamic Proxies (see java.lang.reflect.Proxy) which allows you to wrap all method invocations or an object. This without an outside tool. This is how a lot of j2ee app servers do thier magic.

By and large, the more I work in java, and the more I work in Lisp, I realize how lacking java is in dynamic behaviors. The lisp guys yawned when OO became all the rage because, well, it is so easy to do in lisp. If AOP gets big in java, they will yawn at that too:

"Oh, so functions and try blocks are your boundry block for inserting aspect oriented code? Well, *every parenthisis* is ours. Put that in your JVM and smoke it."

Cheers,
prat

Re:My 2 bits... (1)

ed__ (23481) | more than 11 years ago | (#5433561)

i believe the original AOP implementation was in a LISP dialect. (check out the paper on cisteseer).

Re:My 2 bits... (0)

Anonymous Coward | more than 11 years ago | (#5433568)

"Oh, so your ivory tower language has been around for 50 years without ever entering the mainstream? Put that in your Y combinator and smoke it."

Portable.NET uses AOP for the C# compiler: treecc (2, Insightful)

manyoso (260664) | more than 11 years ago | (#5433458)

One example of Aspect Oriented Programming for compiler writers:

http://www.southern-storm.com.au/treecc_essay.ht ml
http://www.southern-storm.com.au/treecc.html
ht tp://www.southern-storm.com.au/treecc_doc/treecc _1.html#SEC1

It is also rumored that Portable.NET will use treecc for the creation of a JIT engine sometime in the future.

From my limited understanding, Aspect Oriented Programming combines the power of the Visitor and Inheritance patterns without the drawbacks of either.

Another interesting link:
http://www.pcmag.com/article2/0,4149,440611 ,00.asp

Re:Portable.NET uses AOP for the C# compiler: tree (0)

Anonymous Coward | more than 11 years ago | (#5433535)

That is rather limited undestanding. Bog-standard CLOS does that. AOP is like a comprehensive set of :around-method-like extensions to CLOS via the MOP.

People are still adapting to the last big thing (1)

Badgerman (19207) | more than 11 years ago | (#5433474)

From reading the review, I'm not sure Aspects are going to really do much for me. It seems to be "encapsulating" some code needs in an object format, and that's about it.

I see plenty of crappy code all the time. I see lousy use of OOD/OOP. People haven't even adapted to OOD/OOP very well. I can't see this being much more than a technique curiosity that may solve some needs here and there for quite some time to come.

Re:People are still adapting to the last big thing (1)

WeaponOfChoice (615003) | more than 11 years ago | (#5433571)

Agreed, even though I am quite taken with AOP (though it has taken some time to really come up with real world applications for the theory).

In the end, however, it is still limited by the ability of the programmers who are using it - as is OOD/OOP and indeed any programming style at all...

How true (4, Funny)

arvindn (542080) | more than 11 years ago | (#5433479)

It doesn't matter how big and popular the website is.

Yup. Nothing can save it from slashdot.

Other Aspect Oriented Technologies (4, Informative)

Frums (112820) | more than 11 years ago | (#5433495)

Since AspectJ is getting some attention I figured i would point out some other AOP resources

  • MDSOC - Paper [ibm.com] - Is basically IBM's take on AOP. It avoids creating Aspect Space and Object Space (what belongs in an aspect, what in an Object?) but is less mature than AspectJ
  • HyperJ - Home [ibm.com] - IBM's Java language stuff supporting MDSOC
  • JAC - Home [aopsys.com] - Aspect oriented middleware for Java. I haven;t explored this one much, is on my todo list.
  • Aspect Browser - Home [ucsd.edu] - A tool to help identify crosscutting concerns in Java (emacs!)

I urge you all as fellow members to avoid this (0, Troll)

$$$exy Gwen Stefani (654447) | more than 11 years ago | (#5433506)

I urge you all as fellow members to avoid purchasing this book. Save your time and money, as they're both valuable things that this "amazing" new theory that promises to change the world will waste. The creators want us to believe that Aspect will make some programming utopia, but you know what? Hitler said the same thing about his "great new idea" and look where it got him.

Object-oriented is a common sense, practical way to view the world. You treat the variables in your program as objects, and you think about how a real-world object and what its private values would be and what operations you would be able to perform on it. It's a very pragmatic approach.

I've read this Aspect book, though, and it sucks. There's nothing new or innovative, as I'm sure you can see from the Hello World example. Does it look like any ordinary Java or C# code? Yup.

So please, save yourself thirty dollars and a heck of a lot of time and don't ever touch this book. Spend time improving the code you've already written rather than wasting time on theoretical gibberish that won't result in any improved programs.

What we really need is better error prevention, not some new style to program in. Get your priorities straight.

Just natural (0)

Anonymous Coward | more than 11 years ago | (#5433525)

If your OO program is large enough, you naturally begin designing things "aspect oriented" without even knowing that it is called so. If someone needs to explain this to you, you should not be in programming.

disgusting (5, Insightful)

rpeppe (198035) | more than 11 years ago | (#5433585)

Sounds like a disgusting way of trying to legitimise hacks to me. Changing code in ways it wasn't meant to be changed, guaranteed to break lots of things (hence the "horribly easy to accidentally create infinite recursion" reference... no shit Sherlock!)

When will people realise that the most important thing in a programming language is to make it possible to reason about one part of it independent of another part? Most of the time spent developing a program is spent modifying code, not creating new code!

Unfortunately people don't realise this: they just want a way of hacking something existing into something different, cross their fingers and hope that it works when someone changes some other part of the system.

Sadly, it's not just AOP: some of the "usual" OO programming language features suffer this kind of problem too [micro-workflow.com] .

Then again, maybe I'm completely wrong, and AOP has a sound theoretical basis and has been created by someone with deep understanding of programming language developments over the last thirty years... someone please reassure me!

COMEFROM (0)

Anonymous Coward | more than 11 years ago | (#5433600)

People are going crazy over COMEFROM.

AOP Resources (3, Informative)

Vagary (21383) | more than 11 years ago | (#5433604)

The Software Practices Lab [cs.ubc.ca] at UBC has been doing all sorts of AOP research lately. Of particular interest:

  • A study [cs.ubc.ca] to determine whether AOP is actually useful.
  • Implementation [cs.ubc.ca] of all the GoF Design Patterns in both vanilla Java and AspectJ.

They're also working on AspectC and AspectSmalltalk. It's my understanding that UBC is one of the major world centers in AOP research -- do you think I should do a PhD there?

Quite upset Ivan is getting this publicity (-1, Offtopic)

Anonymous Coward | more than 11 years ago | (#5433605)

Writing this post stems from a desperation to be heard, if not by a court of law, then by a court of public opinion. Let me cut to the chase: If you're interested in the finagling, double-dealing, chicanery, cheating, cajolery, cunning, rascality, and abject villainy by which Ivan Kiselev may destroy any resistance by channeling it into ineffective paths by next weekend, then you'll want to consider the following very carefully. You'll especially want to consider that I am tired of hearing or reading that everyone with a different set of beliefs from Ivan's is going to get a one-way ticket to Hell. You know that that is simply not true. Because we continue to share a common, albeit abused, atmospheric envelope, I, for one, find him the most morally questionable person in the world. To cap that off, he is unquestionably up to something. I don't know exactly what, but if you've read any of the scornful slop that Ivan has concocted, you'll really recall Ivan's description of his plan to turn over our country to raving, sanctimonious slackers. If you haven't read any of it, well, all you really need to know is that Ivan is the picture of the insane person on the street, babbling to a tree, a wall, or a cloud, which cannot and does not respond to his assertions.

Even if we accepted Ivan's theories, so what? Does that mean that laws are meant to be broken? Of course not. Ivan's views are a mere cavil, a mere scarecrow, one of the last shifts of a desperate and dying cause.

Mere association tends to lend credence to Ivan's slaves because people assume they can't be that bad if a respected person is associated with them. Well, that's getting away from my main topic, which is that my goal is to hinder the power of headstrong slaves to fashion like him. I might not be successful at achieving that goal, but I unmistakably do have to try. If Ivan is going to talk about higher standards, then he needs to live by those higher standards. We have a number of problems for which he bears most of the responsibility. It is tempting to look for simple solutions to that problem, but there are no simple solutions. He wants all of us to believe that doing the fashionable thing is more important than life or liberty. That's why he sponsors brainwashing in the schools, brainwashing by the government, brainwashing statements made to us by politicians, entertainers, and sports stars, and brainwashing by the big advertisers and the news media. Things that you or I might regard as snippy or ignominious might be considered by Ivan's toadies as an article of faith, a philosophical conviction, a political opinion, or even an innocuous form of entertainment. He vehemently denies that, of course. But he obviously would, because he is reluctant to resolve problems. He always just looks the other way and hopes no one will notice that I overheard one of his apologists say, "We have no reason to be fearful about the criminally violent trends in our society today and over the past ten to fifteen years." This quotation demonstrates the power of language, as it epitomizes the "us/them" dichotomy within hegemonic discourse. As for me, I prefer to use language to put the kibosh on Ivan's viewpoints.

I am sorry to have to put this so bluntly, but the tone of Ivan's imprecations is eerily reminiscent of that of acrimonious used-car salesmen of the late 1940s, in the sense that remaining silent and inactive in the face of Ivan's propositions negates our duty as civilized members of the community. And that's why I'm writing this letter; this is my manifesto, if you will, on how to fight scurrility and slander. There's no way I can do that alone, and there's no way I can do it without first stating that when I'm through with him, he'll think twice before attempting to befuddle the public and make sin seem like merely a sophisticated fashion. I know how most of you feel. This implies that it would be wrong to imply that Ivan is involved in some kind of conspiracy to make individuals indifferent to the survival of their families. It would be wrong because his threats are far beyond the conspiracy stage. Not only that, but he has spent untold hours trying to evade responsibility. During that time, did it ever once occur to him that his pranks are a cancer that is slowly eating away at our flesh? The answer is quite simple. I already listed several possibilities, but because Ivan lacks the ability to remember beyond the last two seconds of his life, I will restate what I said before, for his sake: Even when he isn't lying, he's using facts, emphasizing facts, bearing down on facts, sliding off facts, quietly ignoring facts, and, above all, interpreting facts in a way that will enable him to prevent the real problems from being solved. There's no point in arguing with Ivan. And if that seems like a modest claim, I disagree. It's the most radical claim of all.

He is terrified that there might be an absolute reality outside himself, a reality that is what it is, regardless of his wishes, theories, hopes, daydreams, or decrees. I don't mean to imply that his real enmity against us comes through in his anecdotes, which Ivan uses to restructure the social, political, and economic relationships throughout the entire society, but it's true, nonetheless. There are some simple truths in this world. First, he backstabs his spokesmen. Second, those who believe that his bromides are Right with a capital R are either naive or deliberately misled. And finally, he managed to convince a bunch of refractory survivalists to help him impose ideology, control thought, and punish virtually any behavior he disapproves of. What was the quid pro quo there? A complete answer to that question would take more space than I can afford, so I'll have to give you a simplified answer. For starters, his prevarications are based on two fundamental errors. They assume that arriving at a true state of comprehension is too difficult and/or time-consuming. And they promote the mistaken idea that he is beyond reproach. It is high time for someone to argue about Ivan Kiselev's opuscula. Will that someone be you?

My take on AOP... (4, Insightful)

Fnkmaster (89084) | more than 11 years ago | (#5433612)

I checked this out almost a year ago now, and I'm sure it's come a way since then. First off, AOP is not going to replace OOP or any other paradigm of programming. It simply provides a viable alternative way to think about the control flow and execution of a program, and a shortcut for making more maintainable code.


Anybody who has worked extensively in Java has found this problem before. Cross-cutting concerns - you know, those systemic things that infiltrate their way into every module of your humongo-system, no matter how you try to partition it. Now, object-oriented programming, isn't that supposed to let you "blackbox" things so you can just abstract away such things and throw them in some "common" or "system" package and be done with it? Sure, you can. And you probably have. And I've done it too.


But these solutions can be suboptimal - for example, a project I once worked on had an Interface in the com.blah.blah.system package for logging, messaging, persistence, and some other features. These were always nasty pains in the ass to manage. I mean, some implementor of these objects existed everywhere in the system - if something changed fundamentally, or there was some insuffiency in the interface that was discovered, god forbid, you'd have to root around for hours changing code everywhere. Especially when exception signatures changed. Which eventually leads, in sheer frustration, to using Runtime exceptions everywhere, or declaring all of your "system" interfaces with "throws Exception". Ugh. Each solution seems worse than the problem.


Admittedly, problems like this can be solved with good refactoring tools and practices. But not always well. The exception issue for "system" or "cross-cutting" interfaces was one I've never seen solved well (again, I'm thinking of Java here, it's the language I have the most experience working in large commercial-scale projects in where this stuff is really important). If you are working on medium or small sized open source projects, or medium or small sized tools or desktop applications, you may never have come across these kinds of limitations or frustrations in sufficient numbers to justify looking into AspectJ/AOSD in general. But if you've worked on large enterprise software projects, I'm sure you can see that there is a need to "patch," but certainly not replace, the standard OOP methodology to address these kinds of concerns.

Aspect? (1)

DulcetTone (601692) | more than 11 years ago | (#5433614)

More like Abject? Reject?

tone

Hasn't CLOS had this sort of thing (15 years ago) (3, Interesting)

helixcode123 (514493) | more than 11 years ago | (#5433632)

This sounds similar to the Common Lisp Object System (CLOS) :before and :after methods.
If I remember correctly, in CLOS you can specify a method "foo", and then another method "foo" with the ":before" modifier that would be executed before the normal "foo" method. There is also an ":after" specifier.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?
or Connect with...

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>