¿Han soñado alguna vez con disponer de un software que se pueda amoldar a casi cualquier tipo de negocio, al menos los más comunes, y que según vayan surgiendo nuevos requerimientos como un nuevo negocio, aplicación, módulo, ventana, proceso o lo que sea, simplemente tengan que desarrollar un(os) sencillo(s) bloques de software que utilicen los bloques que ya estaban hechos, quizá removiendo o remplazando algunos y que todos estos bloques integrados conformen una sola estructura estable y coherente?
Ahora permítanme hacer una analogía con algo muy sencillo para que me comprendan mejor. Recuerdo que en mi infancia, mi juego favorito era uno llamado Armotodo, un sistema de fichas tipo LEGO*, seguramente ustedes están familiarizados con dicho juego y por eso no es necesario que me extienda en su descripción, baste con decir que se compone de un conjunto de piezas o bloques de distintas formas y colores que se podían unir para conformar lo que uno quisiera; de hecho parte del Jingle (lema con melodía) decía “todas las figuras que tu quieras construir”.
Seguramente eso les dará una idea la idea tras este tipo de software, pero antes de detallar sus posibles características, analicemos algunos de los problemas y necesidades que trataría de subsanar. Frecuentemente a la hora de encararnos a un nuevo proyecto de desarrollo buscamos reutilizar lo que ya teníamos, recurriendo a copiar, pegar y modificar código, haciendo esto sucesivamente se va creando redundancia y el desarrollo se va haciendo inmantenible.
¿Qué hacer entonces?, bueno, volviendo al Armotodo, este sistema aplica muchas ideas y principios útiles que deben balancearse de manera equilibrada.
Principios
Cada clase de bloque del Armotodo (componente) es única, su forma, color, tamaño y otros, hacen que tenga un propósito definido y diferente o complementario a los demás. En el software, se requiere que los componentes sean fuertemente cohesivos, en su interior pueden suceder muchas cosas, pero al resto de componentes no les debe interesar esto, solo sus propiedades y comportamiento, esto es, un acoplamiento débil. Los bloques conservan una interfaz común (taches y hendiduras) Los componentes deben respetar un lenguaje común aplicando estándares materializados en interfaces efectivas.
Lo único constante es el cambio y eso se puede asimilar con dos cosas reutilización y extensión, el primero es claro, debemos lograr crear componentes no perfectos pero si muy estables, algunos de propósito común como la autenticación de usuarios, encriptación y así por el estilo, otros con una finalidad muy específica, pero siempre pensando en que sean un bloque que podamos volver a incluir en un sistema diferente o en otra parte del mismo para no perder el conocimiento que ya hemos desarrollado. en cuanto a la extensión, siempre deberíamos buscar, en lo posible, no alterar nuestros componentes, de la misma manera que un niño no buscaría aserrar sus bloques para conseguir lo que busca sino que más bien consigue el bloque con las características esperadas y lo agrega a su estructura, para nosotros, crear o mejorar nuestras aplicaciones debe implicar extender.
Los términos claves hasta ahora han sido componente, cohesión fuerte, acoplamiento débil, reutilización y extensión, pero esto necesariamente debe ir acompañado de mantenibilidad o capacidad de mantenimiento, volviendo otra vez a la analogía, seguramente hemos visto como algunos niños comienzan a apilar un bloque encima de otro hasta que la columna finalmente se descompone al caer; debemos vigilar como construimos nuestra estructura para que al tiempo que construimos la afiancemos para que en el futuro sea fácil y efectivo efectuar ajustes.
Cuidados
Hay que ser razonables y tener cuidado para no terminar armando un Sistema o software Frankeninstein, de la misma forma que algunos pueden construir obras de arte con piezas LEGO*, otros hacen cosas sin sentido, hay que tener cierto talento y organización para mantener coherencia y estabilidad en nuestros desarrollos, haciendo selección cuidadosa de cada plan de desarrollo de un nuevo bloque o integración.
Recursos
Hay muchos estándares, prácticas, principios, técnicas y metodologías que se relacionan con las ideas que he expuesto en esta publicación, pero quisiera hacer mención especial de los Frameworks, hay para todo, por eso hay que tener cuidado en su selección, pero un tipo de Framework indispensable es de Inyección de Dependencia (DI) pues lo que nos permite pegar los componentes y/o intercambiarlos según las necesidades, haciendo uso de interfaces efectivas. En cualquier caso, hay que seleccionar cuidadosamente que recursos se emplean, pues algunos son muy compatibles entre sí, mientras que otros chocan.
Hay bastantes modelos, obviamente muchos otros ya han abordado la necesidad de software integrado, para citar un solo caso, el trabajo del grupo P&P (Patterns and Practices) con proyectos como Enterprise Library, SCSF, WCSF, WSSF y más recientemente Prism, todos ellos con una estructura modular, que aplica algunas de las ideas comentadas aquí.
Finalmente, quiero mencionarles que si bien este artículo ha sido muy general, pues no ha entrado en detalles para describir algunas tecnologías referidas en esta entrada, estos temas los estaré tratando más adelante, uno por uno progresivamente al tiempo que voy desarrollando unos tutoriales que serán más que simples Holamundos.
*LEGO es una marca registrada