Diseño De Software Con Patrones

Diseño de software con patrones

En esta serie de artículos (me temo que no entrara en uno), intentare plantearos una iniciación al mundo del diseño de

software con patrones. Quede claro de antemano que los patrones que aquí explique, ni son los únicos, ni son todos los que

hay, no todos los autores les dan los mismos nombres, e incluso quizás no sean los mejores, pero en fin, son los que yo

explicaré porque son los yo que conozco.

En este primer articulo, perdonarme si me excedo con la parte "literaria" y no "entro a lo bestia" con el asunto, pero intentare

simplemente que os entre el "gusanillo" por esta historia y que tengáis cierto interés en posteriores entregas.

¿De donde salen los patrones del software?

Aunque los patrones son algo mas viejo, y su origen es aplicable a otras personas (de hecho al arquitecto Christopher

Alexander que los aplico a la arquitectura en los años 70), solo os contare por que se han vuelto tan "famosos", y porque al

hablar de patrones todo el mundo menciona una cosa llamada "la pandilla de los cuatro" (Gang of Four) o GoF.

El reciente interés del mundo del software por los patrones tiene su origen, o mejor dicho, su explosión a partir de 1995, tras

la aparición y el éxito del libro "Design Patterns: Elements of Reusable Object-Oriented Software" de la pandilla de los

cuatro. Ellos, Erich Gamma, Richard Ele, Rala Johnson y John Vlissides, se dedicaron a recopilar una serie de patrones

(hasta 23) aplicados habitualmente por expertos diseñadores de software orientado a objetos, y al hacerlos públicos... la

"fiebre" estalló, pero como os he dicho, ni son los inventores, ni son los únicos implicados, solo les menciono porque es

realmente imposible leer algo sobre patrones y no hacerlo sobre la GoF.

Por ultimo mencionare a Craig Larman, que es uno de los autores más interesantes que he encontrado sobre el tema, que

ha definido de los patrones GRASP (patrones generales de software para asignar responsabilidades), los cuales

mencionare también aquí.

Dos conceptos clave

Creedme si os digo que ahora, de verdad, quería empezar con el tema de los patrones, pero me temo que no es posible

hacerlo sin aclarar dos términos que aparecerán en muchas ocasiones y que son un objetivo permanente del diseño

orientado a objetos, como son la cohesión y el acoplamiento, que aunque estoy seguro de que muchos de vosotros

conoceréis, los volveré a explicar por si tenemos algún rezagado.

Podríamos definir la cohesión de una clase (o de un paquete, o de lo que sea) como la relación entre los distintos

elementos de la clase, normalmente sus métodos. ¿En cristiano?, pues la cohesión dice que todos los elementos de una

clase tiene que trabajar en la misma dirección, es decir, hacia un mismo fin. Por ejemplo, una clase "Coche" debería

ocuparse de cosas relacionadas con el coche en si, como acelerar y frenar, pero no de cosas ajenas a él como manipular

información referente a su seguro. Como os habréis dado cuenta, la cohesión es una medida relativa, en el sentido de que

depende de lo que cada uno piense que es la función de la clase, pero lo importante es mantener una cohesión lo mas alta

posible. Existen diferentes tipos de cohesión (funcional, secuencial, etc.), pero creerme si os digo que eso ahora mismo no

es importante.

Respecto al acoplamiento, se podría decir que es la interdependencia existente entre dos clases, paquetes, etc. Esto

ocurre normalmente cuando una clase (o paquete) necesita saber demasiados detalles internos de otra para su

funcionamiento, es decir, rompe el encapsulamiento del que tanto se habla en la programación orientada a objetos. También

existen diversos tipos de acoplamiento (funcional, de datos, etc.), pero al igual que ocurría con la cohesión, eso no nos

importa ahora, no es el objetivo de estos artículos. Por supuesto, para tener un diseño correcto, fácil de mantener y modular,

cuanto

...