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.

Patrones De Diseño

Cuando estamos en la tarea de desarrollar un software se nos ocurren diversas formas de empezar y diversas maneras de dar solución a cualquier problema que se nos presente durante el desarrollo de dicho software, pero se nos facilitaria màs y ahorrariamos trabajo si aplicamos algunas soluciones ya especificadas y que anteriormente fueron de utilidad en otros software como los son los patrones de diseño.

¿Què son?
Los patrones de diseño son una solución común, elegante y probada para un problema especifico, son soluciones recurrentes al diseño de software.

Un patrón de diseño es el trabajo de una persona que ya se encontró con el problema anteriormente, intentó muchas soluciones posibles, y escogió y describió una de las mejores, los patrones evitan la continua busqueda de soluciones a problemas ya conocidos y ademas solucionados.

Algunos patrones de diseño son tan importantes que ya vienen incorporados en Java. Otros vienen incluidos en otros lenguajes, tal vez algunos nunca lleguen a estar incorporados a ningún lenguaje, pero continúan siendo útiles.

Si conocemos totalmente el dominio y el problema, puede que sea razonable el uso de patrones desde el principio, depende del desarrollador que patrón utilizar en su software, para esto debe buscar un equilibrio de las ventajas y desventajas que se le surjan al usar cualquier patrón. La presencia de un patron o patrones en un software no es obligatoria solo es aconcejable en caso de tener el mismo problema, siempre teniendo en cuenta que en un caso particular puede no ser aplicable. La aplicación de un patrón no es de manera mecánica requiere una o varias adaptaciones.

No debemos anticiparnos en el uso de patrones de diseño en nuestros programas, primero debemos asegurarrnos bien que si es o son necesarios.

Los patrones de diseño pueden incrementar o disminuir la capacidad de comprensión de un diseño o de una implementación, disminuirla al añadir accesos indirectos o aumentar la cantidad de código.

Tipos de patrones

Los patrones se clasifican en 3 grandes categorías basándose cada una en un propósito:

• Patrones creacionales: tratan con las formas de crear instancias de objetos. Nos ayudan a encapsular y abstraer dicha creación. Entre los patrones creacionales se encuentran: Patrón de Fábrica Abstracta, Patrón Constructor, Patrón del Método de Fabricación, Patrón Prototipo, Patrón de Instancia Única (Singleton).

• Patrones estructurales: describen como las clases y objetos pueden ser combinados para formar grandes estructuras y proporcionar nuevas funcionalidades. Solucionan problemas de composición (agregación) de clases y objetos. Entre los patrones estructurales se encuentran: Patrón Adaptador, Patrón Puente, Patrón Compuesto, Patrón Decorador, Patrón de Fachada, Patrón de Peso Mosca, Patrón Apoderado.

• Patrones de comportamiento: ayudan a definir la comunicación e iteración entre los objetos de un sistema. Reduce el acoplamiento entre los objetos. Entre los patrones de comportamiento se encuentran: Patrón de Cadena de Responsabilidad, Patrón de Comando, Patrón Intérprete, Patrón Iterador, Patrón Mediador, Patrón Memento, Patrón Observador, Patrón de Estado, Patrón de Estrategia, Patrón del Método Plantilla, Patrón Visitante.