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
Ayer en la tarde venía en el tren hacia mi casa, cuando de repente se me ocurrió la idea de escribir algo acerca de inyección de políticas, punteros a función y mi preferencia de .NET antes que Java. Primero, permítanme comenzar con inyección de políticas, es un término que se escucha comúnmente en conversaciones de desarrolladores, pero ¿qué significa ó de que trata? En pocas palabras lo podríamos definir como “Una técnica que se está popularizando con la adopción de la programación orientada a aspectos (AOP), la cual brinda distintos mecanismos para cambiar el comportamiento de objetos de negocios y otras clases a través de la aplicación de políticas, facilitando así la implementación común de conceptos como validación, registro de eventos, manejo de excepciones y caché y muchas más”.
En AOP, se utiliza el término concepto para referirse a una tarea ó característica de una aplicación. Los conceptos claves son características únicas de una clase u objeto, por ejemplo, una clase para conectarse a una BD ó serializar un objeto a disco. Las tareas comunes para una clase u objeto se denomina “funcionalidad transversal” (en inglés, cross-cutting), que en muchas oportunidades un mal manejo de estas trae como consecuencia código duplicado y difícil de mantener sin mencionar aplicaciones poco confiables.
La inyección de políticas fue introducida en .NET por Microsoft con la versión de 3 de su librería de aplicaciones empresarial, la cual trae consigo un componente de inyección de políticas que se integra con los otros componentes de dicha librería. La última versión se puede descargar acá
Sin embargo, me gustaría compartir con ustedes la idea ó el principio de detrás de la “inyección de políticas”, si ustedes son como yo que prefieren diseñar y desarrollar todos los componentes de una aplicación entonces este post puede ser de utilidad.
En mi humilde opinión tenemos dos posibles maneras de “inyectar” bien sea usando Generics y un poco de Reflection ó a través del uso de Callbacks (delegados), a continuación describiremos las dos:
1-. Haciendo uso de Generics: Generics fue introducido en .NET 2.0 y nos ofrece la posibilidad de escribir código más “genérico” esforzando la tipificación de los datos, es decir, no más casting a Object para conseguir reutilización múltiple. Supongamos que tenemos la siguiente clase
La cuál implementa la interfaz ISample que posee un sólo método PerformAction que arroja una excepción si el segundo actual es par (esto para simular que algo falla con la ejecución de dicho método), nótese que no tenemos manejo de excepciones en ese método. Ahora supongamos que tengo un montón de clases que implementan la misma interfaz pero con la misma carencia de manejo de excepciones, ¿en ese caso qué puedo hacer? Sí tomamos en consideración las definiciones de concepto y funcionalidad transversal, podemos entonces decir: Tengo distintos conceptos (porque aunque la interfaz implementada es común su implementación es distinta) pero a su vez tengo funcionalidad transversal, es decir, todas mis clases que implementan la interfaz ISample necesitan un manejo de excepciones.
Una vez dicho eso, obsérvese el siguiente fragmento de código
Es una clase genérica a la cual restringimos su uso para objetos que implementen la interfaz ISample además que su utilización requiere una instancia de objeto, en el constructor a través de Reflection obtenemos información de la clase usada con la clase genérica, es decir, el objeto al cuál le aplicaremos la “política”. La clase genérica tiene sólo un método llamado Execute que invoca ó llama a su vez al método PerformAction de la clase que implementa ISample y agrega manejo de excepciones la cual no existía en la implementación original.
La manera de utilizarlo desde el cliente ó nuestra aplicación sería así
Nótese que no tuve que modificar el código original sino que hago uso de otro mecanismo, en este caso “inyección de políticas” que a través de una clase genérica que actúa como proxy el cuál me permite conseguir lo que quiero, así aislando mis conceptos pero tomando en consideración la funcionalidad transversal.
2-. Haciendo uso de Callbacks: Los Callbacks, punteros a función ó delegados se refieren al mismo mecanismo de pasar código ejecutable como argumento a otro código. En la vieja escuela C/C++ podríamos conseguirlo así
Sin embargo en .NET lo hacemos así
Entonces la manera que podríamos lograr ó conseguir la “inyección de políticas” difiere un poco de la descrita previamente que es más limpia, adecuada, fácil de mantener y la recomendada desde mi punto de vista, porque hacemos uso de un Proxy que se comunica con la clase a la cual se le aplica la política; caso que difiere de hacerlo con un Callback como se muestra a continuación
La mayor diferencia como se puede notar, es que el código que pertenece a la política está del lado del cliente y no en el proxy como tal, permitiendo así repetir código y poner en riesgo el mantenimiento futuro. Podemos conseguir lo que queremos pero no es la mejor manera de hacerlo, sin embargo este segundo enfoque es realmente útil para casos en los cuales, por ejemplo quiera impersonar a un usuario para correr un fragmento de código
Cambiando de tema y ya casi para finalizar, una de las razones por la cual prefiero .NET en vez de Java es por el soporte y uso de Callbacks los cuales están con nosotros desde siempre y son muy útiles como el caso de la función qsort (Implementación de quicksort en el CRT) que acepta como último argumento una función que se encarga de comparar los elementos que se desean ordenar sin mencionar el poder de pasar funciones a funciones. En Java, esto simplemente no “existe” si no hay que “simular conseguirlo” a través de la implementación de interfaces (Patrón de Callback) por lo que me pregunto, ¿qué rayos es eso? Lo puedo hacer en C/C++ en código nativo y en cualquier lenguaje .NET sin implementar ningún tipo de “patrón” para así enfocarme en el requerimiento, por esta y muchas otras razones que .NET me hace más productivo lo prefiero antes que Java.
Saludos,
Angel