Fog Creek Software
Discussion Board




Need help with Aspect Oriented Programming

Hi -

I'm having a little trouble getting my brain wrapped around the whole AOP thing.  I have read through a couple articles, and what I am getting is that while OOP is good for creating a vertical hierarchy with commonalities established by inheritance, AOP establishes commonalities in a horizontal fashion, cutting across a hierarchy.  What I'm not really clear on is what it's for - exactly why would I do this?

Also, are the attributes I'm seeing in .Net just a MS term for aspects?  Is it really the same with a different name, or has MS done something else?

Many thanks in advance.

Aaron F Stanton
Sunday, March 07, 2004

I don't know much about aspect oriented programming. What I know about it doesn't particularly impress me, because I haven't seen any examples where it really looks all that useful. All the articles I've read on the subject reuse the same one or two examples -- usually things that are easily handled in C and C++ using macros. Someone else should dive in here if I'm missing some point.

Joel Spolsky
Fog Creek Software
Sunday, March 07, 2004

AOP adds additional functionality to an existing
code without modification of that code. You may think
about it as of invisible try/catch around specific points
of your application. The difference is that aspects do
"catch" not only exceptions, but also method invokations,
fields access, and generally any condition one may express
programmatically.

Classic example is the transaction management. One may
wrap specific methods (declared in some external textual
file, for example) as requiring transaction; then aspect will
start a transaction at the moment before method
invokation, and commit/rollback it after method return.

AOP is hard (or unconvenient) to implement in C/C++.
It mostly lives in reflection-aware langs (Java/C#).

Vladimir Dyuzhev (http://dozen.ru)
Monday, March 08, 2004

C/C++ programmers have been doing all the things AOP is used for in the last 20 years (have no idea how old C is, honestly) with macros. Well, Java does not have preprocessor, hence AOP.
Don't get me wrong - I like AOP more then macros in the way I like ANT over MAKE. However, nothing revolutionary (which is good, have allergy to revolutions). Just a more structured way to do the old stuff.
By the way, aren't they going to use the template programming (the kind where you make the compiler calculate factorials) for AOP? I think I saw some sample code about template programming which looked very AOP.
What is AOP in .NET? Java has it's AspectJ ... Is there an AspectN?

Alex Chalucov
Monday, March 08, 2004

(hope this isn't too far off-topic) Has anyone found a good (i.e. automated) way to write all the forwarding functions for the pimpl idiom in C++?

class FooImpl {
  int dothis(int);
  int dothat(int);
};

class Foo {
  FooImpl *impl;
  int dothis(int);
  int dothat(int);
};

and then you need
int FooImpl::dothis(int a) { return impl->dothis(a); }
int FooImpl::dothat(int a) { return impl->dothat(a); }
etc etc...

this is one of the big turn-offs of C++ for me. Simple things sometimes require a lot of repetitive code.

Dan Maas
Monday, March 08, 2004

> ...easily handled in C and C++ using macros. Someone else should dive in here if I'm missing some point

I believe the word is "obliviousness". There's a bit of a discussion going on on the AOP list at the moment, courtesy of Christopher Diggins' attempt to add AOP to C++.


Monday, March 08, 2004

Well, of course you can do everything with macros in C++, but thats not a valid criticism in my eyes, since you can do object oriented programming in C. Just take the following example:

C++:

class Point
{
public:
  Point();

  void move(const Point& point);

private:
  int m_iX;
  int m_iY;
};

could be translated into C:

struct Point
{
  int m_iX;
  int m_iY;
};

void PointConstructor(Point* pThis);
void PointMove(Point* pThis, Point* point);

That's what many C-Libraries do, but I would consider OO style as something revolutionary that has happened 20 years ago since the abstractions an object-oriented language provides allows you to design your solution at a higher level of abstraction in a more clear fashion than you can emulate with procedural languages.

AOP just adds one more step in the abstraction game. It was built on the observation that regardless of how good you design your system (e.g. choose the right abstractions and design appropriate modules) there are always aspects of your system that can't be modularized (and gatherd in one place, e.g. a class) but are orthogonal concepts and thus are "distributed" through the whole code base. Transactions were named here already and another default example are Logging mechanisms.

Thomas Holl
Monday, March 08, 2004

One place we've found it useful in QA is fault-injection.  It's easy to write aspects that will cause exceptions that may be hard to cause through more normal means.

It's another way to bullet-proof the application--to make sure that if in some bizarre way variable x gets set to null (even though you should never be able to have such a condition), you can still handle the case.  Because some user somewhere will figure out a way to set x to null.

I think that our usage also shows up the big problem with AOP, though--you can use an aspect to completely destroy the modularity of the original code, causing bugs throughout the system, where neither the programmer of the original code nor the programmer of the aspect quite understands the impact of what they're doing.

Gav

Gav
Monday, March 08, 2004

Intersting point, Gav. Especially if you want to check the coverage and "robustness" of the unit tests you have written, this could be an way to programatically introduce bugs to see if your unit tests reveils them.

I'll have to try this for myself some time...

Thomas Holl
Monday, March 08, 2004

Doesn't the visitor pattern basically do the same thing (in C++) as aspects?

Dan
Tuesday, March 09, 2004

"""Doesn't the visitor pattern basically do the same thing (in C++) as aspects?"""

No.  Not even close.

An emerging phrase to describe AOP is: "the ability to assert qualified statements over oblivious code".  Qualified statements means that I can describe a category of code upon which operations are to be performed.  Oblivious code means that you can assert those statements over code that wasn't written with AOP in mind.

In other words, AOP is more like a smart form of global search-and-replace that happens at compile time or runtime instead of at edit time.

That's *almost* like macros, in that C at least lets you redefine any symbol you want.  Except that in AOP, you'd describe groups of things you wanted to have happen, and the AOP tool would define the macros for you and silently add the right header files to each C source file, so that you could have different things happening in each place.  And, you wouldn't be limited to having the macro work the same way all through a given source file.  Etc., etc.

Phillip J. Eby
Tuesday, March 09, 2004

Macros are not comparable with AOP. Yes, they can serve the same purpose, but macros pollute the sources. Macros are programmatic
approach, AOP is declarative.

As SQL is superior to BerkeleyDB, so AOP is superior to macros and any other programmatic control injection.

If you take a look at EJB, the AOP is clearly seen there: programmer writes the code, and deployer declares what services shall be applied to that code (transaction, security, caching, fail-over, ...). That's the reason why EJB is so popular, IMHO. And, with the come of lightweight container (such as SpringFramework) and AOP the same functionality becomes available with less efforts.

Vladimir Dyuzhev (http://dozen.ru)
Tuesday, March 09, 2004

Yes, macro, preprocessor and templates aren't AOP.  Check the citeseer papers for subjective, adaptive and aspect-oriented programming.  The idea is a complement to object-oriented programming and answers the question "where do I put this stuff that doesn't belong in my objects" and tackles the problem that classes like MultiThreadedLoggingSecureDebugVersionCat try to handle through interface/multiple-inheritance/or deep hierarchies in an attempt to get clean and atomic objects w/ few dependencies (ie nasty design pattern graphs).  And delaying some decisions until after compile time if necessary.

.Net uses attribute-based (declarative) programming, a different approach to the same problem.  Decorating code comments with inert statements that can be invoked later.
Such as xdoclet for Java or the meta facilities for new Java.

Puffy
Tuesday, March 09, 2004

"EJB is so popular"? I don't think it is all that popular. Right now there's a thread on Javalobby asking if folks use EJBs at all: http://www.javalobby.org/thread.jspa?forumID=61&threadID=11754

AOP is very interesting but the non-locality of aspects can also make the code harder to follow. I am not yet convinced to use it on production projects.

AJ
Tuesday, March 09, 2004

*  Recent Topics

*  Fog Creek Home