Patrones de Diseño

Se le da el nombre de acople o dependencia al grado en que un componente de software (una clase, un módulo, una biblioteca) depende de otros componentes, de tal manera que al tratar de modificar uno, es necesario modificar otros. El acople guarda una relación inversa con la cohesión, de modo que a menor acople resulta una mayor cohesión. La cohesión es preferible ya que está asociada a características tales como robustez, confiabilidad, capacidad de ser reutilizada y comprensibilidad, en vez de tener las características de ser difícil de modificar, probar, reutilizar e incluso de comprender.

Este análisis se remonta a la década de los 80 y fue principalmente elaborada por Larry Constantine (1). En cierto modo es el antecesor del movimiento más contemporáneo de patrones de diseño popularizado por “la banda de los cuatro” en su libro Design Patterns (2). La literatura sobre los patrones de diseño es hoy bastante amplia y si nos hemos limitado a citar apresuradamente estas dos referencias no es en demérito de otras excelentes producciones sino porque es relativamente sencillo pesquisar otras fuentes en el Internet.

Hoy día el desarrollo de software está cada vez más orientado al análisis y la aplicación de patrones de diseño ya que estos sintetizan el resultado de observaciones empíricas que se han acumulado en las últimas décadas y conceptos formales de ámbitos más teóricos tales como el análisis numérico. Poco a poco parece construirse un edificio que podríamos denominar meta-programación. Esto no se refiere a la meta-programación con plantillas al estilo C++, donde se abstraen y resuelven un sinnúmero de problemas en la etapa de compilación. Más bien los patrones de diseño también influencian estas áreas un tanto arcanas de la programación próxima al fierro para convertirse en una suerte de morfología de la programación, irrespectivamente del lenguaje utilizado y en consonancia con el problema a mano.

Sin embargo muchos estudiantes (y practicantes) de ingeniería de sistemas, si bien por lo general están algo familiarizados con los patrones de diseño, poca importancia le dan a estudiar el tema de acople, del cual a mi juicio surgen posteriormente las precisiones del caso. Recordemos como mínimo entonces la clasificación más general que Constantine proponía para entender el grado de acoplamiento. De mayor a menor acople tenemos:

- Acople por contenido: un módulo modifica o depende directamente de los detalles de implementación de otro módulo.
- Acople común: ocurre cuando más de un módulo depende de datos globales.
- Acople externo: ocurre cuando dos módulos comparten un formato de datos, un protocolo o un interfaz de dispositivo impuesto por factores externos.
- Acople por control: ocurre cuando un módulo controla la lógica de otro módulo al pasarle información sobre qué tiene que hacer.
- Acople por estampado: ocurre cuando más de un módulo comparte una estructura de datos pero utilizan esa estructura de forma parcial.
- Acople por datos: Ocurre cuando dos módulos intercambian datos a través de parámetros, por ejemplo.
- Acople por mensajes: La forma más suelta de acople. Los módulos no guardan dependencias entre ellos, sino que utilizan un interfaz público para intercambiar mensajes sin parámetros.

Si bien hoy día esta clasificación de acople puede ser adaptada a sistemas orientados a objetos, por ejemplo (cosa que básicamente no existía en la época en que Constantine desarrolló estos conceptos, excepto en centros de investigación avanzada), retomar las ideas originales permite desarrollar perspectiva de lo que hacemos hoy (para no estar condenados a repetir la historia como diría Toynbee) y mirar con ojos frescos la artesanía actual de modo que brille la originalidad, la elegancia, la robustez y la adaptabilidad al cambio.

Adolfo Carpio
Orand

Referencias:
(1) http://en.wikipedia.org/wiki/Larry_Constantine.
(2) Gamma, Erich; Helm, Richard; Johnson, Ralph y Vlissides, John. Design Patterns: Elements of Reusable Object-Oriented Design. Addison-Wesley. 1995. ISBN 0-201-63361-2.

volver