Patrones Creacionales

Los patrones creacionales son patrones que abstraen el proceso de instanciación. Procuran independizar el sistema de cómo sus objetos son creados, compuestos y representados. Encapsulan conocimientos sobre clases concretas usadas por el sistema.

Dentro de los patrones creacionales encontramos a:

Abstract Factory

Aborda el problema de la creación de familias de objetos, ofrece una interfaz para la creación de familias de productos relacionados o dependientes sin especificar las clases concretas a las que pertenecen. Este patrón se conoce también como Kit o toolkit.

Se usa cuando:

Un sistema debe ser independiente de cómo se crean, componen y representan sus productos.

Un sistema debe ser configurado con una familia de productos entre varias. Una familia de objetos producto relacionados está diseñada para ser usada

conjuntamente y es necesario hacer cumplir esa restricción. Se quiere proporcionar una biblioteca de clases de productos y sólo se

quiere revelar sus interfaces, no sus implementaciones.

Este patrón esta recomendado para situaciones en las que tenemos una familia de productos concretos y prevemos la inclusión de distintas familias de productos en un futuro. Algunas consecuencias del uso de Abstract Factory son:

Aísla las clases concretas. Facilita el intercambio de familias de productos. Promueve la consistencia entre productos. Una desventaja es que es difícil dar cabida a nuevos tipos de productos.

Motivación

Un caso relativamente común de uso de este patrón se da en la creación de familias de interfaces gráficos en las cuales los elementos (productos) de la interfaz se mantienen constantes (por ejemplo labels, botones, cajas de texto,…) pero el dibujado de dichos elementos puede delegarse en distintas familias de forma que, en función de la fábrica seleccionada obtenemos unos botones u otros.

Estructura

Participantes

AbstractFactory: declara una interfaz para las operaciones que crean objetos de productos abstractos.

ConcreteFactory: implementa las operaciones para crear productos de objetos concretos.

AbstractProduct: declara una interfaz para un tipo de objeto de producto.

ConcreteProduct: define un objeto producto para que sea creado por la fabrica correspondiente.

Client: usa las interfaces AbstractFactory y AbstractProduct.

Colaboraciones

Normalmente se crea una instancia de alguna ConcreteFactory para la creación de los objetos ConcreteProduct. Esto es en tiempo de inicialización. AbstractFactory delega la creación de productos concretos (ConcreteProduct) en las ConcreteFactory.

Factory Method

Se le conoce como Constructor Virtual, su nombre en español es Método de Fábrica, este patron consiste en utilizar una clase constructora abstracta con unos cuantos métodos definidos y otro(s) abstracto(s): es dedicado a la construcción de objetos de un subtipo de un tipo determinado.

Intención

Define la interfaz de creación de un cierto tipo de objeto, permitiendo que las subclases decidan qué clase concreta necesitan instanciar.

Aplicabilidad

Se usa patron Factory Method cuando:

Una clase no puede anticipar la clase de objetos que debe crear. Se necesita que las subclases especifiquen los objetos a ser creados.

Estructura

Las clases principales en este patrón son el creador y el producto. El creador necesita crear instancias de productos, pero el tipo concreto de producto no debe ser forzado en las subclases del creador, porque entonces las posibles subclases del creador deben poder especificar subclases del producto para utilizar.

Participantes

Product: define la interfaz para los objetos que el factory method crea.

ConcreteProduct: implementa la interfaz de Product.

Creator:

Declara el método factoría, que devuelve un objeto de tipo Product (se puede dar una implementación por defecto).

Puede invocar al factory method para crear un objeto Product.

ConcreteCreator: redefine el factory method para que devuelva la instancia de ConcreteProduct que le interesa.

Colaboraciones

El patrón Creator delega en las subclases la creación de los objetos.

Consecuencias

Eliminan la necesidad de especificar las clases de los objetos creados.

El código solo trabaja con interfaces.

Desventaja. Es posible que los clientes tengan que crear una subclase de creador solo para crear un objeto.