Policy injection, function pointers and why I prefer .NET instead of Java
Yesterday afternoon I was coming home on the train, when suddenly I had this idea of writing something about policy injection, function pointers and my preference of using .NET instead of Java. Firstly, allow me to get started with policy injection, it’s a definition commonly used in developer talks but, what does it mean? Or what is it about? In a few words we can define it as “one technique becoming increasingly popular by the adoption of Aspect Oriented Programming (AOP), which provides an array of mechanisms to change the behavior of business objects and other classes by applying policies thus making it easier to implement crosscutting concerns such as logging, validation, exception handling, caching and more”.
The terminology of AOP uses the word “concern” to mean a task or feature of an application. Core concerns are the features usually unique to a class or object, for example, a class to connect to a database or serialize an object to disk. Tasks common to more than one class or object are crosscutting concerns. Poor management of these can result in duplicated and hard-to-manage code, and unreliable applications.
Policy injection was introduced by the Microsoft patterns & practices group into the release (version 3.0) of their Enterprise Library which integrates with the other application blocks in the library. The latest version can be downloaded here
However, I would like to share with you the idea or principle behind “Policy injection”, if you’re like me that prefer designing and writing all the components for an application by yourself, this can be a useful post to you then.
In my humble opinion, we have at least two possible ways to “inject” either by using generics or through callbacks (delegates), let’s proceed to describe them:
1-.Using Generics: Generics was introduced in .NET 2.0 and it gives us the ability to write “generic” code plus enforcing type-safety, I mean, no more casting to object to achieve multiple reuse. Let’s suppose we have the following class
It implements the ISample interface which contains a single method PerformAction that throws an exception if the time’s current second is even (we do this to simulate that something goes wrong during the execution of this method), please note that we don’t have any exception handling in that method. Now, let’s suppose that I have heaps of classes implementing the same interface without any exception handling mechanism too, what could I possibly do in that case? If we take into consideration the definitions for concern and crosscutting concern we can then say: I have different concerns (even when the implemented interface is the same) but at the same time I have crosscutting concerns, I mean, all of my classes implement this interface without a proper exception handling mechanism.
Having said that, let’s have a look at the following code fragment
It’s a generic class and its usage is restricted to ISample objects plus requires the creation of a new instance, in its Ctor, through Reflection we collect information of the class used with the generic class, I mean, the object we’ll be applying our “policy” to. The generic class contains only a method called Execute which invokes the PerformAction method of our class implementing ISample hence exception handling is added which it didn’t exist in our original implementation.
The implementation on the client or application would be like this
Please note that I didn’t have to modify the original code but I’m using another mechanism instead, in this case “Policy injection” through a generic class that acts as a proxy which allows me to achieve what I want plus isolating concerns from each other but considering crosscutting concerns.
2-.Using Callbacks: Callbacks, function pointers or delegates refer to the same mechanism for passing executable code as an argument to another code. In old C/C++ school we can do it like this
However in .NET we do it like this
So the way we can achieve “policy injection” through callbacks differs a little from the one previously explained, which is cleaner, easier to maintain and suggested from my point of view, because we use a proxy that communicates with the class we’re applying the policy to; if we’re using callback it would be something like this
The greater difference between the two approaches, it’s that policy code is on the client side and not in the proxy class, so code is repeated and future maintainability is at risk. We can achieve what we want but it’s not the best approach to follow, however this method it’s pretty useful in situations such as, impersonating a given user to execute a piece of code.
Changing topics and almost wrapping up, one of the reasons I prefer .NET instead of Java it’s because of Callbacks support which have been with us for a long time ago and they’re a pretty useful as we can see, for instance, the qsort function (quicksort implementation in CRT) which expects to receive as last parameter a Callback to a comparison function. In Java we don’t have this functionality out-of-the-box but we need to “simulate it” by implementing interfaces (Callback pattern) and I start wondering, what the heck? I can do this in C/C++ using native code and in any other .NET language without implementing any “pattern” so I can focus on the requirement, for reasons like this and many other reasons I prefer .NET instead of Java because it just makes me more productive.
Regards,
Angel