El builder pattern, o patrón de construcción, es uno más de los patrones creacionales de diseño. En términos generales un builder esconde los detalles de la creación de un objeto final que se llama producto. Hay varios métodos para lograr esto, y por ello hay varias “implementaciones” de este patrón que en nada coinciden , salvo en el nombre. El clásico, usado en el GoF es un poco más complejo del que vamos a ver ahora, pero no se asusten, ya tendremos la oportunidad de aprenderlo. En esta ocasión nos vamos a enfocar en un builder que se llaman interfaces fluídas (fluid interfaces).

Y seguimos con la política de que la mejor manera de entender, y de aprender, es con un ejemplo. Estuve dándole vueltas a un buen caso para ejemplificar y se me ocurrió este: supongamos que vamos a hacer un programa para una empresa que ofrece servicios de web hosting (alojamiento en web). Esta empresa tiene varios planes que ofrecer: tiene un plan personal, un plan bronce, uno plata, uno oro y finalmente el diamante. El personal ofrece un alojamiento de 10MB, una transferencia mensual de 100MB, una cuenta de correo electrónico y nada más. El bronce ofrece 100MB de alojamiento, 1000MB de transferencia mensual, 10 cuentas de correo electrónico. Así sucesivamente cada plan aumenta las cantidades de alojamiento, transferencia y cuentas de correo. A la cada plan agrega nuevas características. El plata ofrece acceso ssh, y una base de datos; el oro agrega estadísticas de sitio y panel de control. Así se van multiplicando las opciones, y para crear la aplicación definimos nuestro objeto que queda así:

package com.guisho.software.patrones.builder;
 
import java.math.BigDecimal;
 
/**
 *
 * @author guisho.com, luishernan@gmail.com
 */
public class PaqueteDeHosting {
 
    /*Los siguientes campos son obligatorios siempre*/
    private String nombre;
    private BigDecimal precioAnual;
    private int capacidadDeAlmacenamiento; //en MB
    private int transferenciaMensual; //en MB
    private int cantidadDireccionesCorreo;//
 
    /*Las siguientes son opcionales, hay planes que no los tienen*/
    private int cantidadSitiosPermitidos;
    private int cantidadBaseDeDatos;
    private String codigoOferta;
    private boolean accesoSsh;
    private boolean panelDeControl;
    private boolean estadisticasDeSitio;
    private boolean ipPublica;
 
    public PaqueteDeHosting(){
 
    }
 
    /* mas constructores */
    /* Setters, getters y demás código....*/
}

Bien, ahora cada plan tiene una configuración previamente establecida, que el vendedor no arma en el momento, y que preferiblemente no puede cambiar. ¿Cómo hacemos para crear cada objeto? La primera manera que se nos ocurrirá es crear un constructor pada cada caso, manteniendo siempre los valores obligatorios. Tendríamos una colección de constructores como la siguiente:

    public PaqueteDeHosting(String nombre, BigDecimal precioAnual, int almacenamiento, int transferencia, int cantidadCorreos) {
        this.nombre = nombre;
        this.precioAnual = precioAnual;
        this.capacidadDeAlmacenamiento = almacenamiento;
        this.transferenciaMensual = transferencia;
        this.cantidadDireccionesCorreo = cantidadCorreos;
    }
 
    public PaqueteDeHosting(String nombre, BigDecimal precioAnual, int almacenamiento, int transferencia, int cantidadCorreos, int basesDatos) {
        this.nombre = nombre;
        this.precioAnual = precioAnual;
        this.capacidadDeAlmacenamiento = almacenamiento;
        this.transferenciaMensual = transferencia;
        this.cantidadDireccionesCorreo = cantidadCorreos;
        this.cantidadBaseDeDatos = basesDatos;
    }
 
    public PaqueteDeHosting(String nombre, BigDecimal precioAnual, int almacenamiento, int transferencia, int cantidadCorreos, String ipPublica) {
        this.nombre = nombre;
        this.precioAnual = precioAnual;
        this.capacidadDeAlmacenamiento = almacenamiento;
        this.transferenciaMensual = transferencia;
        this.cantidadDireccionesCorreo = cantidadCorreos;
        this.ipPublica = ipPublica;
    }
 
    public PaqueteDeHosting(String nombre, BigDecimal precioAnual, int almacenamiento, int transferencia, int cantidadCorreos, String ipPublica,int basesDatos){
        this.nombre=nombre;
        this.precioAnual=precioAnual;
        this.capacidadDeAlmacenamiento=almacenamiento;
        this.transferenciaMensual=transferencia;
        this.cantidadDireccionesCorreo=cantidadCorreos;
        this.ipPublica=ipPublica;
        this.cantidadBaseDeDatos=basesDatos;
    }
....

Como vemos solo hicimos un par de combinaciones con la cantidad de bases de datos y la ip pública. Mientras la cantidad de campos opcionales crece, la cantidad de constructores aumenta desmedidamente creando el ambiente ideal para que aparezcan errores.

Otro camino que se puede tomar es el clásico bean: un constructor vacío y setters para cada parámetro que deseamos agregar. Este método tiene un pequeño inconveniente: podemos dejar al objeto en un estado incosistente: podemos ponerle cuántas cuentas de correo pero no ponerle nombre, ni ponerle precio. ¿Qué hacemos entonces? Hacemos un Builder!! El builder se explicará por el solo. Veamos:

En PaqueteDeHosting hacemos un constructor con los campos que siempre van para evitar estados inconsistentes:

    public PaqueteDeHosting(String nombre, BigDecimal precioAnual, int almacenamiento, int transferencia, int cantidadCorreos) {
        this.nombre = nombre;
        this.precioAnual = precioAnual;
        this.capacidadDeAlmacenamiento = almacenamiento;
        this.transferenciaMensual = transferencia;
        this.cantidadDireccionesCorreo = cantidadCorreos;
    }

Y creamos el builder

package com.guisho.software.patrones.builder;
 
import java.math.BigDecimal;
 
/**
 *
 * @author guisho.com, luishernan@gmail.com
 */
public class PaqueteDeHostingBuilder {
    private  PaqueteDeHosting paquete;
 
    public PaqueteDeHostingBuilder(String nombre, BigDecimal precio, int cantidadAlmacenamiento, int transferenciaMesual, int cantidadCorreo){
        this.paquete.setNombre(nombre);
        this.paquete.setPrecioAnual(precio);
        this.paquete.setCapacidadDeAlmacenamiento(cantidadAlmacenamiento);
        this.paquete.setTransferenciaMensual(transferenciaMesual);
        this.paquete.setCantidadDireccionesCorreo(cantidadCorreo);
    }
 
    public PaqueteDeHostingBuilder catidadSitiosPermitidos (int cantidad){
        this.paquete.setCantidadSitiosPermitidos(cantidad);
        return this;
    }
 
    public PaqueteDeHostingBuilder cantidadBaseDeDatos (int cantidad){
        this.paquete.setCantidadBaseDeDatos(cantidad);
        return this;
    }
 
    public PaqueteDeHostingBuilder accessoSsh(boolean acceso){
        this.paquete.setAccesoSsh(acceso);
        return this;
    }
 
    public PaqueteDeHostingBuilder panelControl (boolean panel){
        this.paquete.setPanelDeControl(panel);
        return this;
    }
 
    public PaqueteDeHostingBuilder codigoOferta(String codigo){
        this.paquete.setCodigoOferta(codigo);
        return this;
    }
 
    public PaqueteDeHostingBuilder ipPublica (String ip){
        this.paquete.setIpPublica(ip);
        return this;
    }
 
}

Si lo analizamos el builder simplemente envuelve al objeto que creará, con una especie de métodos de acceso (parecido a un JavaBean) pero con la peculiaridad que se devuelve a sí mismo siempre. ¿En qué nos ayuda esto? Miremos el cliente como crea un Paquete ahora:

    public static void main(String[] args) {
 
        PaqueteDeHosting personal = new PaqueteDeHostingBuilder("personal",new BigDecimal(100),10,100,1).build();
        PaqueteDeHosting bronce =
        new PaqueteDeHostingBuilder("bronce",new BigDecimal(200),100,1000,10).accessoSsh(true).build();
        PaqueteDeHosting plata =
        new PaqueteDeHostingBuilder("plata",new BigDecimal(300),100,1000,50).accessoSsh(true).catidadSitiosPermitidos(10).cantidadBaseDeDatos(1).build();
        PaqueteDeHosting oro =
        new PaqueteDeHostingBuilder("oro",new BigDecimal(500),100,4000,100).accessoSsh(true).catidadSitiosPermitidos(100).cantidadBaseDeDatos(5).ipPublica("10.10.10.10").build();
 
    }

Como vemos esto es mucho más sencillo de leer (aparte que la línea se alarga un poco, podríamos hacer varias líneas), y deja al objeto siempre en un estado consistente. Este método de construcción por medio de llamadas encadenadas se llama interfaces fluídas, y es el punto de inicio para muchos lenguajes como Groovy, que crean construcciones bastantes complejas a partir de Builders sencillos que permiten muchas configuraciones.

De nuevo, este no es el Builder de GoF, que veremos en otra ocasión, pero es otro concepto de Builder. Tiene la ventaja que es fácil de entender y de implementar. Imagino que ya se les ocurrió varias maneras de implementarlo en su código actual, así que manos a la obra y a dejar bonito el código! Finalmente les dejo el código fuente de los ejemplos aquí.

Related posts:

1. Singleton Pattern — Patrones de diseño
2. Abstract Factory Pattern – Patrones
3. Factory Pattern – Patrones

Estamos abordando ahora un tercer patrón creacional, o de creación. El Singleton Pattern, a diferencia de los dos que ya hemos visto y los que veremos, no se encarga de la creación de objetos en sí, sino que se enfoca en la restricción en la creación de un objeto. Este patrón es ampliamente utilizado por muchos frameworks, y también es uno de los más fáciles de aprender y utilizar. 

Siempre que se crea un objeto nuevo (en Java con la palabra reservada new) se invoca al constructor del objeto para que cree una instancia. Por lo general los constructores son públicos. El singleton lo que hace es convertir al constructor en privado, de manera que nadie lo pueda instanciar. Entonces, si el constructor es privado, ¿cómo se instancia el objeto? Pues a través de un método público y estático de la clase. En este método se revisa si el el objeto ha sido instanciado antes. Si no ha sido instanciado, llama al constructor y guarda el objeto creado en una variable estática del objeto. Si el objeto ya fue instanciado anteriormente, lo que hace este método es devolver la referencia al estado creado anteriormente. 

En los patrones anteriores utilizamos un Traductor. Imaginemos que el traductor carga a memoria no sólo números, pero también diez mil palabras obtenidas a través de un archivo de texto o un web service. Cada vez que este objeto se cree utilizará mucho espacio en memoria. Además, si se usa un web services para cargarlo, cada carga consume muchos recursos de red y tarda mucho en terminarse de construir. 

Traductor estará disponible para toda la aplicación, y en cualquier lado que se despliegue un texto será invocado. No tendría mucho sentido construir un Traductor cada vez que lo querramos utilizar. Lo más sano sería utilizar un sólo Traductor para toda la aplicación. ¿Cómo lograrlo? A través de un Singleton. Omitiendo la lógica del objeto, el código que se debería usar quedaría algo así:

public class Traductor{
      private static boolean instanciated=false;
      private static Traductor traductorInstance;
 
     /**
       *Notar que el constructor es privado!
      */
      private Traductor(){
          //cargar un diccionario a memoria  a través de un WebService.
     }
 
    public static Traductor getTraductor(){
           if (! Traductor.instanciated){
                 Traductor.traductorInstance= new Traductor();
                 Traductor.instanciated=true;
           }
          return Traductor.traductorInstance;
   }
 
    public String translate(String toTranslate){
       //mucho código bonito va aquí
    } 
 
}

En cualquier lugar de la aplicacion que se quiera utilizar hacer una traducción se hace esto:

Traductor.getTraductor().translate("unaPalabra");

¿Qué logramos con esto? Que alguien que utilice nuestro código no pueda hacer esto

Traductor t = new Traductor();

Es un gran beneficio porque podemos controlar mejor, cambiarla en el futuro, optimizarla, a Traductor. Evita malos usos de la clase y se nos asegura que a lo más hay una instancia del objeto en toda la aplicación.

Las cosas no son tan fáciles como parecen. Hay muchas maneras de crear los Singletons. En este ejemplo utilizamos un booleano estático, pero no siempre es necesario, pudimos haber inicializado traductorInstance como null, y en vez de verificar la variable booleana, verificar si la instancia es null o no.

public class Traductor{
      private static  Traductor traductorInstance=null;
      /**
       *Notar que el constructor es privado!
      */
      private Traductor(){
          //cargar un diccionario a memoria  a través de un WebService.
     }
 
    public static Traductor getTraductor(){
           if (! Traductor.INSTANCE==null){
                 Traductor.traductorInstance= new Traductor();
           }
          return Traductor.traductorInstance;
   	}
 
    public String translate(String toTranslate){
       //mucho código bonito va aquí
    } 
 
}

O, para hacer las cosas más fáciles (que no siempre conviene, jeje) podríamos evitar la evaluación en getTraductor y crear el objeto cuando lo declaramos:

public class Traductor{
      private static  Traductor traductorInstance=new Traductor();
      /**
       *Notar que el constructor es privado!
      */
      private Traductor(){
          //cargar un diccionario a memoria  a través de un WebService.
     }
 
    public static Traductor getTraductor(){
           return Traductor.traductorInstance;
   	}
 
    public String translate(String toTranslate){
       //mucho código bonito va aquí
    } 
 
}

Fácil ¿no? Mmm, pues se puede complicar. En Java por ejemplo, todavía se podría obtener una copia de traductor así:

Traductor t = (Traductor)Traductor.getTraductor().clone();

Para evitar esto tendríamos que añadir las siguietnes líneas a nuestra clase Traductor

     public Object clone() throws CloneNotSupportedException {
         throw new CloneNotSupportedException();
       }

También alguien podría extender la clase y volver público el constructor. Para evitar esto sería buena idea declarar nuestra clase como final.

Hay que tener especial cuidado cuando el Singleton se utiliza en un ambiete multi hilos, porque puede crear problemas si no se implementa de la manera adecuada. En Java es posible que tengamos que meter algún synchronized por ahí para evitar problemas.

Concluyendo, la idea central del Singleton es esa: asegurar de que exista tan solo una instancia del objeto en toda la aplicación. Hay muchas maneras de implementar un Singleton (aquí solo vimos algunas). Es un patrón muy aplicado en Java, aunque, como todos los patrones, se puede implementar en cualquier lenguaje orientado a objetos. También se pueden hacer cosas interesantes uniendo el Singleton con otros patrones creacionales (recordemos que el singleton no busca crear, sino que limitar la creación).

Related posts:

1. Builder Pattern, Interfaces Fluidas– Patrones de diseño
2. Factory Pattern – Patrones
3. Abstract Factory Pattern – Patrones

Los patrones creacionales (creational patterns) son aquellos que tienen que ver con la creación (duh!) de objetos. La razón de ser de estos patrones es para facilitar, ordenar, o ayudar en la creación de objetos. Dependiendo del lenguage de programación que estemos utilizando, generalmente crearemos un objeto así: Objeto o = new Objeto(). Pues bueno, en los patrones creacionales las cosas cambian un poquito, y probablemente ahora crearemos un objeto así Objeto o = ObjectoFactory.getInstance(“x”);, o algo parecido.

Hoy hablaremos del más famoso de los patrones de creación: en Factory Pattern (Patrón de fábrica). Utilizaremos los nombres ingleses porque creo que son más claros que las traducciones que se podrían hacer. Además, en software de todos lados, es más estandar utilizar el inglés en ciertas nomenclaturas para facilitar que otros lean nuestro código. Buhh, alguien alega por ahí, pero reconzcámoslo: programamos en inglés. 

Como todo se entiende mejor con un ejemplo -al menos eso creo yo-, comenzaremos con uno. Supongamos se nos encarga crear un traductor que devuelva los números del cero al diez en tres idiomas: inglés, español, y alemán. Existen muchísimas maneras de hacer esto. Al final, se desea un método que reciba un entero entre 0 y 10 y que devuelva una cadena con el nombre de dicho número en el idioma que se esté trabajando. 

Una manera de entrarle al problema podría ser algo así:

public class MainClient {
public MainClient(){
     }
 
	public traducirNumero(String idioma, int numero){
		if (idioma.equals("español")){
		  switch (numero){
		     case 0: return "uno";
		     case 1: return "dos";
		    ....
		   }
		}
 
		if (idioma.equals("english")){
		    switch (numero){
		     case 0: return "one";
		     case 1: return "two";
		    ....
		    }
		} 
 
		if (idioma.equals("deutsch")){
		    switch (numero){
		     case 0: return "eins";
		     case 1: return "zwei";
		    ....
		    }
		}
	}//traducirNumero
       
public static void main(String args[]){
MainClient mc = new MainClient();
System.out.println(mc.traducirNumero("espanol",1));
}
}//de la clase

 El resultado del código anterior, como ya sabrán, es uno.

Esta solución parece funcionar, y de hecho lo hace. Pero imaginemos que ahora nos dicen que desean la traducción de todos los números? Sin duda el código comenzará a crecer. Y claro, ahora tendremos que agregar código de lógica para cada idioma para escribir números como 752, 1233, etc. 

Como nos gusta hacer gala de nuestro enfoque a objetos, los primero que se nos ocurre es una herencia. Definiremos una clase abstracta Traductor, y para cada idioma haremos una subclase de Traductor.

public abstract class Traductor{
 
   public abstract String traducirNumero(int numero);
 
}

Y ahora comienza la magia a aparecer. Vamos a crear una clase especializada para diccionario, que se encargará de traducir los números. Tendremos una clase especializada para traducir los números al español, que iría algo así:

public class TraductorEspanol extends Traductor {
 
    public TraductorEspanol(){
       super();
       ...
    }
 
    public String traducirNumero(int numero){
       switch(numero){
       	   case 1: return "uno";
       	   case 2: return "dos";
       	   ...
       }
    }	
 
}

La clase para el inglés iría

public class TraductorIngles extends Traductor {
 
    public TraductorIngles(){
       super();
       ...
    }
 
    public String traducirNumero(int numero){
       switch(numero){
       	   case 1: return "one";
       	   case 2: return "two";
       	   ...
       }
    }	
 
}

Y la del alemán no la ponemos, porque ya captaron la idea. Ahora, en el momento de querer utilizar un diccionario, se llamaría algo así

Traductor t = new TraductorEspanol();
t.traducirNumero(1);

Entonces, la clase MainClient cambiaría un poco y quedaría así:

public class MainClient {
 
	public String  traducirNumero(int numero){
		Traductor traductor = null;
		if (idioma.equals("español")){
			traductor = new TraductorEspanol();
		}
 
		if (idioma.equals("ingles")){
			traductor = new TraductorIngles();
		} 
 
		if (idioma.equals("aleman")){
			traductor = new TraductorAleman();
		}
		String toReturn traductor.traducirNumero(numero);
                return toReturn;
	}//traducirNumero
     public static void main(String args[]){
          MainClient mc = new MainClient();
          System.out.println(mc.traducirNumero("espanol",1));
     }
}//de la clase

Qué hemos ganado? Primero, nuestro código es mucho más legible. Segundo es bastante más escalable. Podemos agregar el traductor para el francés muy fácilmente. Tercero hemos escondido la manera en la que traducimos a Tradúceme. Por ejemplo, puede ser que las traducciones a chino las vayamos a traer a un web Service. En ese caso TraductorChino se encargaría de hacer todo el ajetreo de conectarse a internet y buscar el web services, pero los demás ni se enteran.

Pero el Factory Pattern no ha aperecido, Es tiempo de irlo a llamar. Bueno, Traduceme está haciendo algo que no le compete: está eligiendo la instancia de Traductor que quiere usar. Imaginen que se usa el traductor en 100 lugares, entonces en cien lugares se tiene que buscar qué clase de Traductor vamos a instanciar. El patrón de fábrica -factory pattern- nos esconde esa lógica. Vamos a agregar ahora nuestra fábrica de traductores.

public class TraductorFactory {
     public TraductorFactory(){
 
     }
 
	public static Traductor createTraductor(int numero){
		Traductor traductor = null;
		if (idioma=="español"){
			traductor = new TraductorEspanol();
		}
 
		if (idioma=="english"){
			traductor = new TraductorIngles();
		} 
 
		if (idioma=="deutsch"){
			traductor = new TraductorAleman();
		}
		return traductor;
	}
}//de la clase

¿Qué hace TraductorFactory? Simplemente elige, en base a los argumentos dados – en este caso el idioma- qué clase de traductor se instanciará. Traduceme de nuevo cambia y quedaría así:

public class MainClient {
     String idioma;
     public static void main(Strin []args){
		Traductor traductor = TraductorFactory.createTraductor("espanol");
		System.out.println( traductor.traducirNumero(1) );
	}//main
 
}//de la clase

MainClient se ha visto dramáticamente reducido, y su código es muy fácil de leer. Quien quiera usar un traductor simplemente hará llamar a Traduceme. Traduceme sabe el idioma que eligieron, pero no sabe que subclase de Traductor instanciar, pero sabiendo el idioma TraductorFactory sabe exáctamente qué instancia de Traductor crear. Si la aplicación desea cambiar de idioma simplemente le envía otro parámetro a Traduceme y listo. También agregar idiomas es más manejable que antes. 

El Factory Pattern esconde al usuario final dle código la desición de qué sublclase instanciar, y promueve el encapsulamiento de las partes más variables del sistema. En términos generales, una fábrica abstracta consiste de las siguientes partes:

• Un cliente, que es el que llama a la fábrica (en nuestro caso MainClient).
• Una fábrica, que decidé la clase a instanciar (TraductorFactory).
• Un prodicto, lo que la fábrica devuelve (para nosotros las instancias de Traductor).

Pueden bajar los fuentes de este ejemplo aqui.

Related posts:

1. Abstract Factory Pattern – Patrones
2. Singleton Pattern — Patrones de diseño
3. Builder Pattern, Interfaces Fluidas– Patrones de diseño