Microkernels

[Jose San Leandro <jose.sanleandro@xxxxxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hola,

¿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.
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. En
concreto, el API que proporciona es básicamente un repositorio de instancias
identificables mediante consultas basadas en su tipo. Dicho repositorio
incluye gestión del ciclo de vida de las instancias, mecanismos de creación
de las mismas, posibilidad de definir su sincronización y privacidad en
entornos concurrentes, etc, así como su configuración.
Al desacoplar (mediante el acoplo a una API intermedia) el acceso a las
dependencias de cada clase, se consigue una mejora significativa en cuanto a
la facilidad de implementar pruebas unitarias, ya que la introducción de
implementaciones tipo Mock[5] es muy simple. Esto beneficia la robustez del
código, y por extensión reduce el número de bugs o acelera su identificación.
Asímismo, el microkernel centraliza también los procesos de creación y
liberación de instancias, con lo que permite definir servicios de
monitorización, logging, etc., muy fácilmente.

Sin embargo, en mi opinión afecta enormemente al diseño OO de la aplicación
que los utilice, independientemente de si es conveniente que sea así o no.
En primer lugar, obliga a que cada clase exporte sus métodos como interfaz
público, aun en el caso de que no tenga sentido más de una implementación. Me
da la impresión que poco menos que obliga a la proliferación de paquetes impl
y/o clases XXImpl. Adicionalmente, se impone la restricción del modelo
funcional del ciclo de vida de los objetos, entendiendo como modelos no
funcionales mecanismos de pooling, garbage collection, etc.
En este sentido, los microkernels no permitirían modelar la evolución de un
objeto como parte del diseño. Básicamente, obligan a una implementación
estática basada únicamente en el paso de mensajes entre objetos.
Otro inconveniente que le veo es la omisión de los antipatrones que conlleva:
qué se puede cachear de la API y qué no, qué puede suponerse (in)variante,
etc.

Si bien el desarrollo guiado por la facilidad de realizar pruebas unitarias es
atractivo, en este caso, en mi opinión, llegan demasiado lejos. Me gustaría
saber si esta tendencia es debida al debate sobre el nombre del patrón
Inversion of Control / Dependency Injection, y sobre si alguno de los
fundadores de XP o metodologías ágiles tienen "la culpa".

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.

Un saludo.
Jose.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAvH7FCAvt6RF8M0cRAhUfAJ9CYnEGRKSt2TCSOdp9SyLr06/etwCfUhcI
Kzo2XTqgRm315UVJW6yLIIk=
=nyOu
-----END PGP SIGNATURE-----