RE: [mindfood] Microkernels

["Rafael Luque Leiva" <rafael.luque@xxxxxxxxxxxxxxx>]

> ¿Alguno de vosotros está utilizando algún microkernel? He echado un 
> vistazo por encima a los que me han parecido más activos, Hivemind[1] 
> y PicoContainer[2], así como Spring[3], aunque éste último es mucho 
> más ambicioso.

Aún no los hemos utilizado en ningún proyecto real, aunque les venimos
siguiendo la pista desde hace algún tiempo, especialmente a
PicoContainer y Spring. 

> Puedo estar equivocado, pero me da la impresión de que lo que se 
> entiende por microkernel es una implementación más o menos flexible 
> del patrón mediador [4], pero extendido a todas las dependencias 
> presentes en el diseño...

Yo veo estos "contenedores IoC", "microkernels" o "contenedores ligeros"
como frameworks de configuración para cumplir con el Principio de
Inversión de Dependencia (DIP). Este es uno de los principios de diseño
que según Robert C. Martin forman la base teórica de la orientación a
objetos, siendo los patrones de diseño formas de llevar a cabo estos
principios más genéricos en determinados escenarios.

El Principio de Inversión de Dependencia, al que ahora muchos se
refieren como "Inversion of Control" (IoC) o patrón Hollywood ("don't
call us, we'll call you"), fue descrito por Martin en un artículo de
1996 [1], con lo que no se trata en absoluto de un concepto nuevo. De
hecho, este es el principio que está detrás de muchos patrones de
diseño: Bridge (GoF), Plugin (Fowler, [2]) o Abstract Server.

Cuando recurrimos al patrón Plugin para desacoplar un componente de la
implementación concreta de algún servicio que requiere, el problema que
aparece es cómo obtiene ese componente una implementación del plugin.

El objetivo de este nuevo tipo de contenedores es resolver estas
dependencias, ensamblando los componentes y las implementaciones de
plugins que se desee utilizar. Para lograrlo, todos se basan en el
mecanismo de "inyección de dependencias" (término acuñado por M. Fowler
en lugar de IoC que considera demasiado genérico [3]). Cada usuario de
un plugin debe seguir determinados convenios que permiten al contenedor
conocer qué plugins requiere cada componente e inyectarle la
implementación correspondiente. El desarrollador tiene que declarar
mediante configuración (programáticamente o mediante archivos de
configuración) cuáles son esas implementaciones.

Por ejemplo, en PicoContainer el convenio se basa en los argumentos
constructor (IoC tipo 3) y en Spring en los métodos setter (IoC tipo 2).

> Es cierto que aún no los he utilizado en ningún desarrollo, y 
> posiblemente mis conclusiones no son
> acertadas. Sin embargo, por ahora espero que no lleguen a ser tan
> utilizados
> como para que Sun decida incorporar una variante de los mismos como
parte
> de
> ninguna especificación. Hay que tener en cuenta el lugar que ocupan
JSP o
> taglibs dentro de las tecnologías recomendadas por Sun.

Me parece que ante este tipo de modas y buzzwords todos debemos mantener
una actitud crítica y un tanto escéptica. Hay que evaluar objetivamente
las ventajas e inconvenientes de cada nueva tecnología, sin dejarse
llevar por la fiebre del evangelista de turno.

[1] <http://www.objectmentor.com/resources/articles/dip.pdf>
[2] <http://martinfowler.com/eaaCatalog/plugin.html>
[3] <http://www.martinfowler.com/articles/injection.html>

Un saludo,