En esta serie de articulos (me temo que no entrara en uno), intentare plantearos una iniciacion al mundo del diseño de software con patrones. Quede claro de antemano que los patrones que aqui 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 articulo, perdonarme si me excedo con la parte "literaria" y no "entro a los bestia" con el asunto, pero intentare simplemente que os entre el "gusanillo" por esta historia y que tengais cierto interes 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 interes del mundo del software por los patrones tiene su origen, o mejor dicho, su explosion a partir de 1995, tras la aparicion y el exito del libro "Design Patters: Elements of Reusable Object-Oriented Software" 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 publicos... la "fiebre" estallo, pero como os he dicho, ni son los inventores, ni son los unicos 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 mas interesantes que he encontrado sobre el tema, que ha definido de los patrones GRASP (patrones generales de software para asingar responsabilidades), los cuales mencionare tambien aqui.
Dos conceptos clave
Creedme si os digo que ahora, de verdad, queria empezar con el tema de los patrones, pero me temo que no es posible hacerlo sin aclarar dos terminos que apareceran en muchas ocasiones y que son un objetivo permanente del diseño orientado a objetos, como son la cohesion y el acoplamiento, que aunque estoy seguro de que muchos de vosotros conocereis, los volvere a explicar por si tenemos algun rezagado.
Podriamos definir la cohesion de una clase (o de un paquete, o de lo que sea) como la relacion entre los distintos elementos de la clase, normalmente sus metodos. ¿En cristiano?, pues la cohesion 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 informacion referente a su seguro. Como os habreis dado cuenta, la cohesion es una medida relativa, en el sentido de que depende de lo que cada uno piense que es la funcion de la clase, pero lo importante es mantener una cohesion lo mas alta posible. Existen diferentes tipos de cohesion (funcional, secuencial, etc), pero creerme si os digo que eso ahora mismo no es importante.
Respecto al acoplamiento, se podria 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 cohesion, eso no nos importa ahora, no es el obejtivo de estos articulos. Por supuesto, para tener un diseño correcto, facil de mantener y modular, cuanto más bajo acoplamiento haya entre las clases (o paquetes), pues mejor.
Introduccion a los patrones del software.
Seguro que en los ultimos tiempos habreis oido muchas veces el termino "patrones del software", pero ¿que son realmente estos famosos patrones?. Los patrones de software no son mas que un conjunto de literatura sobre la resolucion de problemas habituales en el diseño de software orientado a objetos.
Una definicion mas formal podria ser:
Un patron es una solucion 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 patron 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, creerme que no demasiada, 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 patron.
El patron Singleton
El singleton es, posiblemente, el patron mas sencillo que existe. Trata las situaciones en las que solo se permite una instancia de una clase dada.
Veamos un ejemplo, si 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 septimo. ¿Que sucede si un elemento de ese nivel, por ejemplo un termostato en las valvulas 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 patron Singleton, que se asegura de que se producira una sola instancia de coche y de que esta podra ser recuperada en cualquier momento por un metodo de clase, en Java, static.
final class Coche {
/* la unica instancia de coche que se permitira.
No es obligatorio crear el Singleton estaticamente,
se podria proveer un metodo que lo cree
*/
private static Coche c = new Coche();
// atributos
private Motor motor = new Motor();
. . .
// metodo que devuelve el "singleton" Coche
public static Coche getCoche () {
return c;
}
// resto de metodos
public void acelerar() {
// implementacion del metodo
}
. . .
}
Como hemos dicho, solo debe haber una instancia del Singleton, por lo que tambien tenemos que asegurarnos de que no se derive la clase, por ello el modificador de clase final.
Tambien habria que tener en cuenta otras operaciones que crean instancias en Java, como por ejemplo el metodo clone, or lo que habria que sobreescribirlo para que lanzase una excepcion o simplemente devolviese la instancia ya existente.
Y eso es todo
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 proximo explicare un par de patrones mas, el experto y el creador supongo.