Patrones de Software (Parte 1)

Diseño de software con patrones.

Fecha de creación: 15.05.2001

Revisión 1.0.1 (15.10.2002)

Alberto Molpeceres
al AT javahispano DOT org

Copyright (c) 2002, Alberto Molpeceres. Este documento puede ser distribuido solo bajo los términos y condiciones de la licencia de Documentación de javaHispano v1.0 o posterior (la última versión se encuentra en /licencias/).

Introducción

En esta serie de artículos (me temo que no entrará en uno), intentaré 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 quizas no sean los mejores, pero en fin, son los que yo explicaré porque son los yo que conozco.

En este primer artículo, perdonadme si me excedo con la parte literaria y no entro a lo bestia con el asunto, pues intentaré simplemente que os entre el gusanillo por esta historia y que tengais cierto interés en posteriores entregas.

¿De dónde salen los patrones del software?

Aunque los patrones son algo más viejo, y su origen es aplicable a otras personas (de hecho al arquitecto Christopher Alexander que los aplicó a la arquitectura en los años 70), solo os contaré por qué se han vuelto tan famosos", y por qué 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 Patters: Elements of Reusable Object-Oriented Software
[1] de la pandilla de los cuatro. Ellos, Erich Gamma, Richar Helm, Ralph 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 último mencionaré a Craig Larman, que es uno de los autores mas interesantes que he encontrado sobre el tema, que ha definido de los patrones GRASP[2] (patrones generales de software para asingar responsabilidades), los cuales mencionaré 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 conocereis, los volveré a explicar por si tenemos algún rezagado.

Podriamos 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 deberia 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 habreis 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 cohesion lo más alta posible. Existen diferentes tipos de cohesión (funcional, secuencial, etc), pero creedme si os digo que eso ahora mismo no es importante.

Respecto al acoplamiento, se podría decir que es la interdependecia 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 obejtivo de estos artículos. Por supuesto, para tener un diseño correcto, fácil de mantener y modular, cuanto más bajo acoplamiento haya entre las clases (o paquetes), pues mejor.

Introducción a los patrones del software.

Seguro que en los últimos tiempos habreis oido muchas veces el término patrones del software, pero ¿qué son realmente estos famosos patrones?. Los patrones de software no son más que un conjunto de literatura sobre la resolución de problemas habituales en el diseño de software orientado a objetos.

Esta literatura que recoge los patrones empezó teniendo una forma fija, de forma que se existía una especie de plantilla fija (siguiendo el estílo indicado por la GoF), con secciones tales como motivación, explicación, etc, que debía ser rellenada. Algunos autores han desarrollado sus propias plantillas o formato para los patrones, y otros simplmente optan por una descripción más relajada basada en textos sencillos sin orden preestablecido. Yo seguiré esta última aproximación, de forma que debereis referioros a los libros de la bibliografía para encontrar su definición formal.

En fin, volvamos al asunto, una definicion mas formal de lo que es un patrón podria ser:

Un patrón es una solución de diseño de software a un problema, aceptada como correcta, a la que se ha dado un nombre y que puede ser aplicada en otros contextos.

No penseis que son algo mágico, no lo son, y seguro que muchos de vosotros ya habeis utilizado muchos de ellos o con algunas pequeñas diferencias, aunque no supierais que era un patrón ya definido. Como ya he dicho, los patrones son simplemente una manera de resolver problemas del desarrollo del software, fruto de la experiencia, y por esa misma razón, con un poco de experiencia, creedme que no demasiada para algunos, podeis haber llegado a soluciones similares en algunos casos.

Y por fin, para terminar por hoy, para que no os quejeis, os dejo con el primer patrón.

El patrón Singleton.

El singleton es, posiblemente, el patrón más sencillo que existe. Trata las situaciones en las que solo se permite una instancia de una clase dada.

Veamos un ejemplo, tenemos una clase Coche que representa uno de estos coches modernos, controlado totalmente por computador. Este coche esta compuesto de muchos elementos, como por ejemplo el motor, que se compone a su vez de otros, hasta que llegamos a un nivel dado, por ejemplo al séptimo. ¿Qué sucede si un elemento de ese nivel, por ejemplo un termostato en las válvulas tiene que dar un mensaje a la clase Coche?, como por ejemplo, para decirle que muestre un indicador en el cuadro de mandos avisando de una temperatura elevada.

Podriamos ir pasando la referencia al Coche de un nivel a otro, pero eso se hace impracticable, por lo que a veces es conveniente una visibilidad global (aunque pueda implicar un acoplamiento de paquetes, por ejemplo), usando para ello el patrón Singleton, que se asegura de que se producirá una sola instancia de Coche y de que esta podrá ser recuperada en cualquier momento por un metodo de clase, en Java, static.

final class Coche {
/* la única instancia de coche que se permitirá.
No es obligatorio crear el Singleton estáticamente,
se podría proveer un metodo que lo cree
*/
private static Coche c = new Coche();

// atributos
private Motor motor = new Motor();
. . .

//constructor privado para que no se pueda instancia
private Coche(){
//vacío porque creamos la instancia estáticamente
}

// metodo que devuelve el "singleton" Coche
public static Coche getCoche () {
return c;
}

// resto de metodos
public void acelerar() {
// implementación del metodo
}

. . .

}

Como hemos dicho, solo debe haber una instancia del Singleton. por ello el contructor privado, que aunque al ser el singleton una estancia estática no se producirán más instancias, si podría ocurrir que se creen (o se reinicialicen) las clases que contiene, en este caso el motor. También tenemos que asegurarnos de que no se derive la clase, por ello el modificador de clase final.

También habría que tener en cuenta otras operaciones que crean instancias en Java, como por ejemplo el método clone, por lo que habría que sobreescribirlo para que lanzase una excepción o simplemente devolviese la instancia ya existente.

Conclusión

Pues eso es todo por hoy, como habreis visto esto de los patrones no es nada apto solo para gurus, pero tampoco os penseis que todos son como el pobre Singleton, alguno mas interesante ya veremos, pero no ahora. En el próximo explicaré un par de patrones más, el experto y el creador supongo.

Recursos

[1]
Design Patters: Elements of Reusable Object-Oriented Software,
Erich Gamma, Richar Helm, Ralph Johnson y John Vlissides,
Addison Wesley, 1994

[2]
UML y Patrones: Introducción al análisis y diseño orientado a objetos,
Craig Larman,
Prentice Hall, 1999.

Acerca del autor

Alberto Molpeceres
Alberto es es ahora mismo desarrollador de aplicaciones en ámbito cliente/servidor para la empresa T-Systems - debis Systemhaus en Munich (Alemania). Cuando no está trabajando o "metiendo caña" al resto de los integrantes de javaHispano intenta pasear con su novia, buscar la desaparecida lógica del idioma alemán o intentar olvidar la pesadilla que es buscar piso en Munich.