Patrón constructor (Builder)

Este patrón es también conocido cómo Builder

Separa la construcción de un objeto complejo de su representación, de modo que el mismo proceso de construcción permite crear diferentes representaciones.

Estructura:

En la siguiente imagen podemos ver un diagrama UML de este patrón:

Builder pattern

Participantes:

• Constructor o Builder (IBuilder): Especifica la interfaz para la creación de las partes de un Producto.
• Constructor concreto (Builder): Implementa la interface del constructor para construir y ensamblar las diferentes partes del producto. Además almacena el producto en construcción y proporciona una interfaz para recuperar el producto construido.
• Director: Construye un objeto utilizando la interfaz del constructor.
• Producto: Objeto concreto a construir.

Colaboraciones:

• El cliente crea el objeto director y lo configura con el constructor deseado.
• El director notifica al constructor la parte del producto que debe ser creada.
• El constructor añade partes al producto, de acuerdo con las peticiones del director.
• El cliente recupera el producto final del constructor.

Concecuencias:

• Permite variar la representación interna de un producto.
• Aísla el código de la construcción y la representación.
• Proporciona un control más detallado del proceso de construcción.

Implementación:

      En el nivel más elemental, es posible implementar un patrón Builder básico con una única clase Builder que tenga un método de creación y su producto. Para dotarlo de mayor flexibilidad, los diseñadores suelen ampliar este patrón básico con una o más de las siguientes opciones:

• Crear un Builder abstracto. Puede tener un sistema más genérico que sea capaz de albergar muchos tipos distintos de constructores si define una clase abstracta o una interfaz que especifique los métodos de creación.

• Definir múltiples métodos de creación para el Builder. Algunos Builder definen varios métodos de creación (básicamente, sobrecargan su método de creación) para proporcionar distintas formas de inicializar el recursos construido.

• Crear delegados para la creación. Con esta variante, un objeto Director contiene el método de creación general del Producto y llama a una serie de métodos mas granulares en el objeto Builder. En este caso, el objeto Director actúa como gestor para el proceso de creación del Builder.

Patrones relacionados:

• Abstract Factory: El patrón Builder puede ser remplazado con el patrón Abstract Factory para la creación de objetos complejos. Si bien, el patrón Builder se centra en la construcción de objetos complejos paso a paso, el patrón Abstract Factory hace hincapié en familia de objetos.
• Composite: Muchas veces lo que construye el patrón Builder es un Composite.

Les dejo un ejemplo que descargar en C#: Builder_Pattern

Read More

Happy Pattern

     El término “Happy Pattern" apareció por primera vez en el libro “Refactoring to Patterns”. Este término fue utilizado como calificativo aplicado a un programador que utiliza un patrón de manera indiscriminada sin tener en cuenta si este patrón proporciona algún beneficio al diseño, o por el contrario, si este patrón nos lleva a la construcción de un mal diseño.

     Cuando utilizamos un patrón debemos tener en cuenta los beneficios y las consecuencias que implica su uso. Mientras que los patrones nos da una mayor flexibilidad a nuestros diseños. Estos también añaden más complejidad en ellos.

     Siempre debemos considerar que los patrones son un buen punto de partida o de referencia, pero estos no son fundamentos incuestionables.

Read More

Antipatrones

     Todas las disciplinas tienen buenos y malos usos, en este caso “Patrones” y “Antipatrones”. Si un patrón es una buena práctica, entonces, un antipatrón es una mala práctica.

Existen dos tipos de antipatrones:

1. Aquellos que describen una mala solución a un problema y que da como resultado una mala situación.
2. Aquellos que describen como salir de una mala situación y convertirla en una buena solución.

     Los antipatrones son considerados una parte importante del conocimiento, en otras palabras, es muy importante conocer y entender las buenas soluciones y las malas soluciones.

            Los diseñadores intentan evitar los antipatrones siempre que sea posible, pero para esto se debe poder reconocerlos e identificarlos lo antes posible. Los antipatrones más útiles son aquellos que no permiten rehacer un buen diseño a partir de uno malo.

            El concepto de antipatrón puede encontrarse en muchas disciplinas. Pero es ampliamente utilizado en la ingeniería en general.

Se puede definir entonces a un antipatrón de la siguiente forma:

“Forma literaria que describe una solución comúnmente dada a un problema que genera consecuencias negativas decididamente”.

Para la ingeniería del software se pueden clasificar los siguientes tipos de antipatrones

Antipatrones de desarrollo de software:

1. The Blob (“Clases gigantes”).
2. Lava Flow (“Código muerto”).
3. Funcional Fecomposition (“Diseño no orientado a objetos”).
4. Poltergeists (“No se sabe bien lo que hacen algunas clases”).
5. Golden hammer (“Para un martillo todo son clavos”).
6. Spaghetti code (“Muchos if o switch”).
7. Cut-and-paste programming (“Cortar y pegar código")

Antipatrones de arquitectura de software:

1. Stovepipe enterprise ("isolation in the company").
2. Stovepipe system ("isolation between systems").
3. Vendor Lock-In ("dependent product architecture").
4. Architecture by implication.
5. Design by committee ("Swiss army knife").
6. Reinvent the Wheel ("reinventing the wheel").

Antipatrones de gestión de proyectos de software:

1. Analysis paralysis.
2. Death by planning.
3. Corncob ("troublemakers").
4. Irrational management.
5. Project mismanegement.

Read More

Patrones de diseño

     El principal objetivo de los patrones de diseño es guardar la experiencia de diseño de programas orientados a objetos. Cada patrón de diseño nombra, explica y evalúa un diseño importante. En otras palabras, ellos tratan de agrupar la experiencia de diseño de modo que otras personas puedan utilizarla correctamente.

     El uso de patrones nos da la posibilidad de elegir diseños alternativos para que nuestro sistema sea reutilizable. Inclusive, nos pueden ayudar a mejorar la documentación y el mantenimiento de nuestros sistemas. En pocas palabras, los patrones de diseño nos ayuda a alcanzar mejores diseños en un tiempo más corto.

        Aquí tienen una presentación hecha en Prezi, dónde pueden encontrar algunos conceptos básicos para entender un poco más sobre el uso de patrones de diseño.

Read More