Composite Oriented Programming: QI4J running on .NET


For the last month I have been spending my spare time porting the awesome Java framework QI4J to .NET.
QI4J is the brain child of Rickard Öberg and Niclas Hedhman and it attempts to enable Composite Oriented Programming for the Java platform.
(For more info regarding Composite Oriented Programming see the QI4J website: http://www.qi4j.org/ )

I’m well aware that others have been doing spikes on COP for .NET, a few of those attempts can be found here:
http://stackoverflow.com/questions/152196/composite-oriented-programming-cop-net-4-0-mef-and-the-oslo-repository

However, I think it is sad to not reuse all of the effort and brain power that has been put into QI4J, and thus I decided to port it instead.

The code is currently only available from my SVN repository at google code:
http://code.google.com/p/alsing/source/checkout

Please note that the code will be released under the same license as the Java version (Apache License version 2.0)
And copyright notices for the ported code will also be applied to give credit where credit is due.

The .NET version is largely identical to the Java version as it is pretty much a plain class by class port.
However there are a few exceptions:

The concept of “Property<T>” is not available in the .NET version since C# and most .NET languages does support properties out of the box and it would feel awkward to write things like:

“order.Customer.Set(theCustomer)” rather than “order.Customer = theCustomer”

However, the framework does rely on the Property<T> internally and thus most of the state holding infrastructure is also identical to the Java version.

The Java version relies on its own set of query expressions while my plan is to possibly reuse those internally but rather expose a LINQ API for querying.
(I have not yet started to build that)

Currently supported concepts:

Soon to come:

And I will ofcourse post a few samples of what you can do with this ASAP, I just wanted to drop a little sneak peek :-)

//Roger

AOP vs. OOP Ignorance


Yesterday Fredrik Normén wrote a post about crosscutting concerns.
Torkel Ödegaard also wrote a followup on it.

And I did blog about this a few years ago.

Since the topic was brought up, I’ll give it another shot.

Most developers are still having some real issues to grasp the connection between AOP and OOP.

Lets take this from the perspective of C#;

When you decided to use C#, you most likely did so because you thought the language had some qualities connected to it.
One reason is probably because it is object oriented.
C# comes with quite decent OOP support, eg. it supports modifiers that let you communicate to the consumer of your classes if you consider it is safe to alter the behaviour of your classes or not.

The main reason why it is bad to allow every method to be altered is that it is harder harder to guarantee that both your code and your consumers code will still work as intended.
eg. if you are consuming a non virtual method and you know that it will only throw FooExceptions, then you can be certain that you only need to catch FooExceptions.

In the case of virtual methods, you can not be certain of anything and you need to code more defensivly when you consume it.

Most C# developers would agree that inheritance modifiers are a good concept and that this will prevent consumers from using your API incorrectly.

But when it comes to AOP, then most developers throw away all their knowledge of fundamental OOP and get all excited by the power of AOP black magic.

For example, the by far most common argument against proxy based AOP is; “proxy based AOP only works on virtual methods or interfaces”

What developers need to understand is that OOP inheritance and AOP incerception both targets the same problem area;
They are both means to extend and alter the behaviour of your code.

With OOP inheritance you can override the behaviour of a method and either add new behaviours or completely replace the original behaviour.

With AOP interception you can intercept a method and either add new behaviours or completely replace the original behaviour.

See the similarities?

They both do the same thing, but in different ways.

Now if they both do the same thing, and all of our code is designed to conform and play by the OOP rules.
Then the AOP way MUST conform to the same OOP rules or you will get some serious problems.

If AOP were to have it’s own set of rules, then this would completely nullify the rules of OOP;
The “virtual” and “sealed” keywords would not mean anything anymore because you could easily ignore them using AOP.
By ignoring the OOP rules we can no longer use the same way to reason about code as we do today.

You need to choose, either we play by the OOP rules all the time, or we completely ignore them and play by the “alter everything” AOP rules.

And I’m not saying that the latter is a bad choice.

Languages like Ruby are excellent for this, it does not have inheritance modifiers and it also allows you to alter the behaviour of everything.

The key problem here is; C# is NOT designed this way, it is designed to conform to the OOP rules, the entire code-base of .NET is designed to conform to the OOP rules.
Therefore, the “alter everything” approach does not play well with .NET.

You can of-course argue that; “I’ve used Post# successfully w/o breaking anything”.
But it is not really me that you should take that argument with, if you think that the “alter everything” is the way to go, you should say that to Anders Hejlsberg and tell him that he was wrong to include sealed and virtual in C# and that those rules have no purpose.

If you want to be able to extend your code, then you need to make it extensible.
Just because you use an AOP framework that can alter everything doesn’t mean that it is safe to do so.
You have to take the same precautions when extending with AOP as when extending with OOP.

We have come to learn this when we deal with TDD, it requires a certain design in order for your code to be testable.
The same applies to AOP via proxies, you have to design a certain way to make it work.
And luckily, the same design that makes it possible to do TDD also makes it possible to apply proxy based AOP.

The number one argument from the AOP critics is;
“You can not see what is actually going on by looking at the code”

If you play by the OOP rules, the above argument is no more true for AOP than it is for inheritance in OOP.
But if you play by the “alter everything” approach, then that argument is completely true and the critics are right.
I could no longer make an assumption that non virtual method code infront of me does just what it says, it could do something completely different.

 

 

Enjoy.

PS.
Proxy based AOP is the shit ;-)

//Roger

Hidden gem: BuildManager.GetType


I’ve been digging through the ObjectDataSource today and I was trying to figure out how they created the datasource instance from the type name.

Now some clever reader might say “I know, I know, Type.GetType(string)”… But that’s wrong..
Type.GetType(string) requires full type names with assembly name and the whole shebang.

The ObjectDataSource is able to create instances w/o all that information.
So after a while of digging I found a precious gem, hidden in System.Configuration:
“BuildManager.GetType(string)”

Very very nice :-)

I can now inherit ObjectDataSource and fetch the type via buildmanager and then call NAspect to proxy the type and get an AOP enabled datasource.

Thats all for now, just wanted to share this one :-)

Code mangling AOP vs. Runtime Proxy AOP


 THIS IS AN OLD POST FROM MY OLD BLOG (2006) 

AOP is gaining momentum in .NET and there are starting to pop up quite a few AOP frameworks.
A comparison of (some of) those can be found here:
List of existing approaches

As you can see there are a few different approaches to accomplish AOP in .net
the ones that I know are:

  • ContextBoundObject – Inherit ContextBound
  • Source transformation – Extra compile step
  • IL instrumentation – Extra compile step
  • .NET profiling API – Modify the Jitted IL
  • Runtime Subclass proxies – Reflection emit subclasses
  • Runtime Interface proxies – Reflection emit proxies with interfaces

These approaches can be divided into two categories:

  • Inheritance based (Runtime proxies)
  • Code mangling (all the others)

(Ok ContextBound might be a separate category but since its too limited Ill just ignore it ;-) )

So what is the difference between these two approaches?

Code mangling can be very powerful and can modify your code in ways that is not supported by inheritance.
e.g. you could add interception to non virtual members, you could intercept field access and you can change base class of other classes.

Runtime proxies can only intercept ctors, virtual members or interface members.
So runtime proxies are in most cases considered to be the less of the two.
But here is my take on it:

If we take a look at good’ol OO, we have constructs like private, sealed/final, virtual, override etc.
Those constructs all have a purpose, to let the author of a class specify things like:

“It’s all OK to alter the behaviour of this method and things should work all OK if you do because its virtual”

Or:

“You may not alter this method because nasty things might happen”

(e.g. sealed or private etc)

No one has ever questioned those constructs in OOP.
So why should different rules apply to AOP?

the goal is the same as in inheritance, to alter or extend behaviour / functionality of a class.

So in my opinion inheritance based AOP is the way to go because its 100% OO compatible.
It doesn’t break the above rules.

While you might be able to do cool hacks with code mangling, you are also opening up for a whole lot of problems.
e.g., it requires much more of a consumer of a virtual method than a consumer of a non virtual method.

Why?

Because when you consume a non virtual method you know exactly what might happen, you know what exceptions that might occur and you know what the expected behaviour is.
When consuming a virtual method, you don’t know what might happen because you might call the method on your base class or on a subclass and the subclass could have been provided from someone else.
so when you consume the virtual method you might have to add some extra exception handling or make your code a bit more generic because you can’t be certain that things behave exactly as when you call the base implementation.

So if AOP would allow you to break the fundamental OO rules, you could alter the behaviour of a non virtual method and introduce behaviours that is not expected by the consumer.
and I think that is VERY bad.
If the author of the consuming code wrote his code knowing that it was a non virtual method he called, he did not prepare his code for anything else, and the AOP’ed variant of the provider method might screw things up big time.

And since the entire framework is designed w/o AOP in mind, I bet there is plenty of code in both your applications and in the framework itself that simply expects those non virtual methods to behave as they did when the code was written.

So in short, I don’t think AOP should be allowed to break the fundamental OO rules because most of the code you use is designed for those rules.
(However I think its a completely different story with things like AspectJ where the language itself is designed for AOP and those who use it know that every kind of method might be intercepted.)
The next thing is debugging.

Code mangling can accomplish lots of weird stuff like changing the base class of a type or introduce fields.
That might seem like a cool feature but since we all write our code in .NET languages that is NOT designed for AOP, e.g. C# or VB.NET
How are we supposed to debug such code?

The code executing is not the same code you have in your source files.
For me, that is just madness.

In runtime proxies we do not have those problems because the proxies are just dumb objects redirecting your calls to your interceptors, mixins and base methods.
so you will never ever need to debug the proxies themselves since they just redirect the calls.
and your base class and interceptors are still normal .NET code which you can debug just fine.
However there is a scenario where I do agree it is nice to be able to intercept non virtuals.
Debug aspects.
e.g. tracing, code coverage, interaction tests and various mock aspects.
Such aspects is a special case for me since they do pretty much the same as your IDE debugger.
in the debugger you can step into a private method, you can view all private variables etc.
Debug aspects does the same but in a different way.
Well that’s it :-)

And as stated in the beginning, this is just my take on it.
I’m not a fanatic so I could convert if someone just provides me some valid arguments why breaking OO rules is good in AOP :-)

//Roger

NAspect – the first debuggable AOP framework for .NET


THIS IS AN OLD POST FROM MY OLD BLOG (2006)

There are quite a few AOP frameworks for .NET out there today.
But all (?) of them suffer from the same problem, its hard or impossible to debug them.

I myself would pick debugging over AOP any day, so forcing our users to debug via coredbg or such tool was not an option when we started to build NAspect.

NAspect supports an intact callstack when stepping from your consumer code into your interceptors and finally into your real provider method.
Here is a few screenshots:

Place a breakpoint in your consumer code:

Single step into the method, notice how we ended up in our first interceptor instead of the provider method:

Single step into the proceed method, now we arrive at the real provider method.
Note that the call stack is intact and shows all steps from your consumer to your interceptor to your provier method.

This is as far as I know not possible with any other AOP framework for .NET today.

Another problem area when dealing with AOP is to know what interceptors that actually got attached to your method.
You can ofcourse step through the entire call flow and check the callstack, but that is pretty messy if you got a few hundred methods with a few interceptors each.

NAspect support VS.NET 2005 DebuggerVisualizers.
Instead of trying to figure out if your config file works or single step through every method to see the interceptors, we can simply enter debug mode and visualize the AOP’ed instance:

 

On the left side of the visualizer you get a list of all adviced methods in your type,
On the right side you get a list of interceptors for the currently selected method.

The next step will be to build a debugger visualizer that shows an UML graph of the proxied instance, showing what mixins and baseclass it relates to.

//Roger