Las dificultades de reutilización de componentes en la industria del software

Hace mucho tiempo que sabemos que una de las claves de la productividad es construir nuevos componentes o sistemas ensamblando componentes existentes. El proceso de ensamblado de componentes fue el motor de la revolución industrial. La programación orientada a objetos se creó para otorgar al software de esa reusabilidad de componentes y predecía que el software se construiría en el futuro ensamblando componentes preexistentes. Sin embargo, eso no ha sido así a una escala 'comercial'. Los objetos tienen una granularidad excesivamente fina y son demasiado dependientes del contexto. Cuando apareción el CBD o el desarrollo basado en componentes, su objetivo era solucionar estos dos problemas para proporcionar un marco en el cual los componentes pudiesen ser reutilizados. Hay quien dice que la escasa cantidad de componentes disponibles se debe a la dificultad de encontrar el componente que solucione un problema concreto. Pero otros autores achacan el tímido despegue de la reutilizacion de componentes a otros factores. El primer factor es la cantidad de protocolos específicos de las tecnologías. Cuando CBD apareció, CORBA y DCOM eran las tecnologías dominantes para saltar las fronteras tecnológicas. Fueron reemplazadas por Java RMI y por .NET Remoting. Si bien estas tecnologías han tenido relativo éxito, no han podido desligarse de las tecnologías que representan. Entre ellos no funcionan bien. Incluso Java RMI no funciona bien entre distintas versiones. Otro factor es que el empaquetamiento de los componentes y sus especificaciones son muy pobres. Si tienes un conjunto de componentes que podrías utilizar para un propósito dado, es muy difícil saber realmente cómo se comporta cada uno, que recursos consumen, que rendimiento tienen o que vulnerabilidades puede tener un sistema que lo use. La especificación no se ocupa de estos términos. La especificación UML, como ejemplo de esto, no es ni de lejos suficiente para atender a estas necesidades. Por último, está el método de encapsulación. Los componentes no se están generando de manera que puedan ser parametrizados para responder a las necesidades del sistema que los va a utilizar. Este problema es difícil de superar, puesto que hacer un componente parametrizable es caro. Pero es en muchas ocasiones la forma de encapsular dicho componente, y no de desarrollar más. Encapsular una clase monolítica puede tener estos problemas, pero hay que definir exáctamente qué es el componente. En esto vivimos en la industria del software, con este problema. Algunos frameworks dependientes de la tecnología (Objective-C para iPhone, .NET, ExtJS) tienen componentes muy bien definidos, pero es muy difícil cruzar las barreras de dependencia tecnológica con ellos. De una forma o de otra, creo que hay bastante que aprender de estos frameworks, pero están lejos de contener las especificaciones necesarias para actuar de la forma adecuada para una real industrialización del software.