FACTORY METHOD

Factory Method permite la creación de objetos de un subtipo determinado a través de una clase
Factory. Esto es especialmente útil cuando no sabemos, en tiempo de diseño, el subtipo que
vamos a utilizar o cuando queremos delegar la lógica de creación de los objetos a una clase
Factory. Utilizando este patrón podemos crear instancias dinámicamente mediante la
configuración, estableciendo cual será la implementación a utilizar en un archivo de texto, XML,
properties o mediante cualquier otra estrategia.

Los componentes que conforman el patrón son los siguientes:

IProduct: Representa de forma abstracta el objeto que queremos crear, mediante esta interface se
definen la estructura que tendrá el objeto creado.

ConcreteProduct: Representa una implementación concreta de la interface IProduct, la cual es

creada a través del ConcreteFactory.

AbstractFactory: Este componente puede ser opcional, sin embargo, se recomienda la creación de
un AbstractFactory que define el comportamiento por default de los ConcreteFactory.

Concrete Factory: Representa una fábrica concreta la cual es utilizada para la creación de los
ConcreteProduct, esta clase hereda el comportamiento básico del AbstractFactory.
BUILDER

Este es un patrón bastante simple pero muy útil, el cual nos permite crear objetos complejos a
través de uno más simple. Es muy común encontrarnos con situaciones en las cuales tenemos que
crear objetos compuestos de forma manual y repetidas veces, lo que nos lleva a tener que
establecer cada propiedad del objeto y si ésta además tiene objetos compuestos dentro, tenemos
que crearlos primero para después ser asignados al objeto que estamos creando. Esto desde luego
que se hace una tarea tediosa y cansada, sobre todo cuando tenemos que crear de manera
frecuente los objetos.

Los componentes que conforman el patrón son los siguientes:

IBuilder: Este componente no es obligatorio en todos los casos, sin embargo, es buena práctica
especificar una interface común que tendrán todos los Builder que definiremos en nuestra
aplicación, puede ser una interface que defina únicamente el método build.

ObjectBuilder: Esta es la clase que utilizaremos para crear los TarjetObjet, esta clase debe de
heredar de IBuilder e implementar el método build, el cual será utilizado para crear al
TarjetObject. Como regla general todos los métodos de esta clase retornan a si mismo con la
finalidad de agilizar la creación, esta clase por lo general es creada como una clase interna del
TargetObject.

TarjetObjet: Representa el objeto que deseamos crear mediante el ObjectBuilder, ésta puede ser
una clase simple o puede ser una clase muy compleja que tenga dentro más objetos.
OtherObjets: Representa los posibles objetos que deberán ser creados cuando el TarjetObject sea
construido por el ObjectBuilder.
PROTOTYPE

El patrón Prototype basa su funcionalidad en la clonación de objetos, estos nuevos objetos son
creados mediante un pool de prototipos elaborados previamente y almacenados. Este patrón es
especialmente útil cuando necesitamos crear objetos basados en otros ya existentes o cuando se
necesita la creación de estructuras de objetos muy grandes, este patrón nos ayuda también a
ocultar la estrategia utilizada para clonar un objeto.

Los componentes que conforman el patrón son los siguientes:

Client: Componente que interactúa con los prototipos.

IPrototype: Este componente por lo general es una interface y define los atributos mínimos de un
prototipo, esta interface debe contar por lo menos con alguno de los dos tipos de clonación.
Clonación superficial (clone) o clonación en profundidad (deepClone) los cuales explicaremos más
adelante.

ConcretePrototype: Implementaciones concretas de IPrototype los cuales podrán ser clonados.

PrototypeFactory: Componente que utilizaremos para mantener el cache de los prototipos

existentes, así como para crear clonaciones de los mismos.
ABSTRACT FACTORY

El patrón de diseño Abstract Factory busca agrupar un conjunto de clases que tiene un
funcionamiento en común llamadas familias, las cuales son creadas mediante un Factory, este
patrón es especialmente útil cuando requerimos tener ciertas familias de clases para resolver un
problema, sin embargo, puede que se requieran crear implementaciones paralelas de estas clases
para resolver el mismo problema, pero con una implementación distinta.

La estructura de Abstract Factory puede resultar muy enredosa ya que tiene muchos componentes
y éstos aparentemente se mezclan entre sí.

Client: Representa la persona o evento que dispara la ejecución del patrón.

AbstractProduct (A, B): Interfaces que definen la estructura de los objetos para crear familias.

ConcreteProduct (A, B): Clases que heredan de AbstractProduct con el fin de implementar familias
de objetos concretos.

ConcreteFactory: Representan las fábricas concretas que servirán para crear las instancias de
todas las clases de la familia. En esta clase debe existir un método para crear cada una de las
clases de la familia.
AbstractFactory: Define la estructura de las fábricas y deben proporcionar un método para cada
clase de la familia.