BUILDER

Patrón	Builder
Descripción	El patrón Builder permite crear un objeto complejo usando objetos simples y un enfoque de pasos. Este tipo de patrón viene bajo la gama de patrones creacionales y proporciona una de las mejores maneras para crear un objeto. Una clase Builder construye el objeto final paso por paso. Es importante mencionar que el Builder es independiente de otros objetos. Su principal objetivo es separar la construcción de un objeto complejo de su representación. El resultado a nivel computacional será más o menos el mismo, ya que el proceso de “ensamblado” debe realizarse de todos modos. La diferencia radica en que la lógica del programa no necesita saber cómo ensamblar el objeto, sino únicamente aquellas piezas que quiere que éste disponga.
Cuando usarlo?	Cuando se tiene instanciar objetos complejos que generalmente están compuestos por varios elementos y que admiten diversas configuraciones.

-       Builder

o      interfaz abstracta para crear productos.

-       Concrete Builder

o      implementación del Builder

o      construye y reúne las partes necesarias para construir los productos

-       Director

o      construye un objeto usando el patrón Builder

-       Producto

o      El objeto complejo bajo construcción

 

Cómo funciona el patrón Builder?

El director invoca los servicios del Builder e interpreta su formato. El Builder crea parte del objeto completo, cada vez que es llamado y mantiene todos los estados intermedios. Cuando el producto es finalizado, el cliente obtiene el resultado del Builder.

Ofrece un control más fino sobre el proceso de construcción. A diferencia de los demás patrones creacionales, el patrón Builder construye el producto paso por paso bajo el control del director.

a.       S-ingle Responsibility Principle

                      I.        ¿Qué significa S-ingle Responsibility Principle?

Dicta que todos las clases o módulos deben tener responsabilidad sobre una sola parte de la funcionalidad dada por el software, y esa responsabilidad debe estar totalmente encapsulada por la clase. Todos sus servicios deben estar estrechamente alineados con esa responsabilidad.

                    II.        ¿Puede no cumplirse? Si se cumple. Dado que la tarea del Builder es siempre crear un producto basado en ciertas propiedades.

b.       O-pen Close Principle

                      I.        ¿Qué significa O-pen Close Principle?

Los módulos deben estar abiertos para la extensión, pero cerrados a la modificación, esto es, que una entidad debe permitir modificar su comportamiento a través de la extensión, pero sin modificar su código fuente.

           II.            ¿Puede no cumplirse?

Si se cumple, cuando se agregan nuevos Concrete Builder no hay necesidad de modificar el Abstract Builder.

c.    L-iskov Substitution Principle
        I. ¿Qué significa la L-iskov Substitution Principle?

           Básicamente que cada clase que hereda de otra, puede usarse como su padre sin necesidad de conocer las diferencias entre ellas.

       
        II.  ¿Puede no cumplirse?

             Sí se cumple. De hecho, el Builder está creado para crear siempre objetos con las misma características. Es posible hacer una sustitución de una clase que herede de una clase A, por otra clase que también esté heredando de la clase A, sin causar problemas en las clases, pues siempre estarán formadas de las mismas caracteristicas.

 d.     I-nterface segregation
          I. ¿Qué significa la I-nterface segregation Principle?

             Establece que ningún cliente debe ser forzado a depender de métodos que no utiliza. Se deben dividir interfaces grandes en otras pequeñas basadas en grupos de métodos, sirviendo a submodulos.

 
          II.  ¿Puede no cumplirse?

                Sí se cumple. El builder esta creado para usar solo los métodos necesarios en cada grupo de concreteBuilder. Y dividido en partes pequeñas de productos.

e.      D-ependency inversion:

          I. ¿Qué significa D-ependency inversion?

             "Los módulos de alto nivel no deberían depender de módulos de bajo nivel, ambos deberían depender de abstracciones" y "Las abstracciones no deberían depender de detalles sino que los     detalles deberían depender de las abstracciones". Esto significa que en ningún lugar de nuestro     código deberíamos depender de una implementación actual, sino que en su lugar debemos     depender de interfaces o clases abstractas. ¿Y por qué deberíamos hacer esto? Porque esto nos     habilita a cambiar cualquier implementación por otra y ninguna otra clase que hayamos codificado debe saberlo o importarle. Si, es así, a ninguna otra clase debe importarle que el cambiemos un colaborador por otro.

            II. ¿Puede no cumplirse?

                 No se cumple, ya que el concrete builder depende directamente del builder, para evitar este inconveniente es necesario implementar una interfaz y que la clase builder la implemente de esta manera builder no sabrá lo que sucede en su clase principal y se pueden hacer cambios sin importarle.