Aspect Oriented Programming: Has anyone tried it?

General Discussions
#1

I have recently been taking a look at Aspect Oriented Programming. It seems like an interesting compliment to OOP and I can see some potential uses in game development. Looking at AspectJ it looks like the overhead is all (or mostly?) at compile time with little to no run time overhead.

Has anyone tried AOP programming before and if so what were your impressions?

#2

A great way to obfuscate software systems.

#3

It’s a solution looking for a problem. We tried it at work, it just complicated stuff. We removed it completely and never looked back.

#4

Decoupling functionality and stitching it back together with regex/patterns is a great way to ensure job security. I steered clear of this (anti)pattern because it was so obviously nuts. Clicking through code - using your IDE - is invaluable when tracing the flow of your code. AOP scatters your decoupled code around your code base, leaving your IDE and you clueless when debugging. It seems like its finally on the way out though, people are dropping it left and right.

Learn from the mistakes others made, if you don’t see the disadvantages right away :slight_smile:

#5

and then you made LibStruct :wink:

#6

I don’t see how there is any irony or contradiction there, honestly. Structs don’t change flow, they give you control over the memory layout of your data.

#7

oh … i was refering to myself trying to catch the code flow of LibStruct. breakpoints always work, it’s just nebulous with the agent in the middle :slight_smile:

#8

Points taken. One of the things that piqued my interest in AOP is the ability to possibly consolidate code that might be spread across various classes into a smaller set of aspects. Counter balancing that was the worry about making the same code less comprehensible.

#9

Well it has it’s purpose, pretty much limited to profiling and logging :smiley:

#10

I’ve always thought it was a bad direction. Rewritting rules are useful. Contracts are useful. The two of these give you most of aspects. Toss in knowing how to perform various forms method dispatching and you’re done. Aspects as a debugging tool seems like shoehorning in a use-case.

#11

Wel AOP in Java is normally mostly used to simulate Traits or Mixins. Maybe a reasonable usecase.

#12

A bit long and not the most dynamic speaker but here is a talk attempting dispel some myths about AOP.

#13

What AOP appears to give me is similar to what the addition of a 3rd dimension to graphics gives me: all sorts of cool possibilities, and massive headaches.

Cas :slight_smile:

#14

That to me? I’ve mostly seen pre & post conditions (so contracts). And I’m covering mixin’s by dispatch and composition. Trait’s seems like a really painful thing to mimic with aspects…but then again it all seems kinda painful to me.

#15

Contracts would most likely be far more useful to more people than the whole mess that AOP seems to be.

Still haven’t quite come up with a decent use case beyond injecting logging either. Stuff like transaction handling is critical to functionality and logic and I seriously wouldn’t want to leave it in the hands of a bit of code miles away which I had no idea was even executing… whereas logging isn’t.

What might have been nice in Java is a way to annotated how extension points in abstract classes were meant to be used. I find myself using this pattern a lot:


public final void tick() {
	doTick();
}
protected abstract void doTick();

or this:


public final void tick() {
	doTick();
}
protected void doTick() {
	// By default, do nothing special
}

with the expectation that the derived class implements doTick(). However what is the rule for a further derived class? I end up with having to remember to do this:


@Override
protected void doTick() {
	super.doTick(); // Don't forget to do this FIRST or everything breaks!
	// blah
}

or this:


@Override
protected void doTick() {
	// blah
	super.doTick(); // Don't forget to do this LAST or everything breaks!
}

or even this:


protected final void doTick() {
	// blah
	doTickMoreStuff();
}
protected abstract void doTickMoreStuff() {

… and so on. Some keywords or annotations to help enforce the accepted method of extension would solve a lot of that.

I digress. Back to work. In C#. Gah.

Cas :slight_smile: