Qué son los patrones de diseño en Java

COMPARTIR 0 TWITTEAR

introduccion_patrone_diseño

Siguiendo con nuestro curso de programación en esta ocasión vamos a introducir los patrones surgen por la necesidad de tener siempre disponible un buen diseño al que podamos ampliar su funcionalidad sin tener que modificar todo lo que hicimos o tener que meter cosas incumplan nuestras reglas básicas de diseño.

Christopher Alexander conocido por su obra A Pattern Language. Towns, Buildings, Construction dijo en 1977 que:

Cada patrón describe un problema que se repite una y otra vez en nuestro entorno, y describe el núcleo de la solución a dicho problema, de modo que pueda usarse esta solución millones de veces, aunque siempre de forma ligeramente distinta.

Es decir, nos plantea una serie de patrones que servirán para resolver unos determinados problemas. Tenemos que tener claro que:

  • Un patrón software proporciona un esquema general.
  • Somos nosotros los que debemos implementarlo, por lo general el lenguaje no nos da un prototipo para ser usado.
  • Los patrones sirven en determinadas ocasiones, para que el software funcione y sea eficiente no tiene porque estar basado en uno o varios patrones. Nunca se deben meter los patrones “a calzador” o usarlos para resolver problemas triviales.

Los patrones pueden atender a distintas clasificaciones entre los que destacamos:

  1. Arquitectónicos.
  2. De diseño.
  3. Centrados en el código o patrones de implementación (únicos de un lenguaje de programación).

Nosotros nos centraremos en los patrones de diseño, en concreto los patrones de diseño ligados a lenguajes estáticos como puede ser Java. Nos interesan estos tipos de patrones porque se sitúan en un punto intermedio entre los arquitectonicos y los de implementación, nos da más variedad de lenguajes, así como un cierto grado de flexibilidad a la hora de migrar de un plataforma a otra.

Por todo esto que hemos hablado nosotros basaremos todos nuestros artículos en el libro Design Patterns o GoF (Banda de los cuatro, en alusión a su cuatro autores). Es el libro clásico por excelencia de patrones de diseño. En podemos ver un catálogo de 23 patrones divididos en tres áreas: de creación, estructurales y de comportamiento.

Nuestro primer patrón

El primer patrón, no tanto por su utilidad si no por su sencillez es el patrón Singleton. Imaginemos que queremos garantizar que una clase tenga una única instancia, es decir, ¿Cómo podríamos garantizar que de dicha clase sólo exista un único objeto? Imaginemos que tenemos una clase Logger que permita mostrar mensajes de traza en una aplicación.

  1. Debemos evitar que se pueda llamar a new desde fuera de la clase. Hacemos privado (o protegido) el constructor de la clase.

    public class Logger{

    private Logger()    {   
        // ...  
    }   
    

    }

  2. ¿Quién crea esa única instancia? Necesariamente tendrá que ser desde dentro de la clase.

    public class Logger{

    private static final Logger instance    = new Logger(); 
    
    private Logger()    {   
        // ...  
    }   
    

    }

  3. ¿Cómo acceder a dicha instancia única desde fuera de la clase? Hay que proporcionar un punto de acceso a dicha única instancia.

    public class Logger{

    private static final Logger instance    = new Logger(); 
    
    private Logger()    {   
        // ...  
    }   
    
    public   static Logger getInstance() {  
            return instance;    
    }
    

    }

Esto que hemos hecho es el patrón Singleton. Tenemos que tener claro que:

  • Al poder acceder a ellos desde cualquier lugar de la aplicación se comportan como variables globales.
  • Que sean singletons no quiere decir que tengamos que obtener la única instancia necesariamente a través de su método estático getInstance(). También podemos pasarlos como parámetros a las clases cliente que lo necesiten, como haríamos con cualquier otro objeto.

Hasta aquí el artículo de hoy, ¿que pasaría si queremos dos tipos de Logger? introducimos una primera variante: ahora nos surge la necesidad de tener dos tipos de logger (de consola y fchero), manteniendo la misma restricción de que sólo haya un único objeto. ¿Cómo podríamos solucionarlo?

Archivado en Curso de Programación, Java, Patrones de diseño
COMPARTIR 0 TWITTEAR

Comentarios (5)

Usa tu cuenta de Facebook para dejar tu opinión.

¿Te ha gustado? ¡No te pierdas nada más!

follow us in feedly

Otras webs de Difoosion