Patrones Creacionales_Singleton

Singleton

Es quizás uno de los patrones de diseño más sencillos, es también uno de los más conocidos y utilizados. Ofrece una mejora sobre las variables globales. Su propósito es asegurar que sólo exista una instancia de una clase, hace que la clase sea responsable de su única instancia, se le conoce tambien como patrón de instancia unica.

Intención

Garantiza que una clase sólo tenga una instancia y proporciona un punto de acceso global a ésta instancia.

Aplicabilidad

Usar cuando:

• Deba haber exactamente una instancia de una clase y ésta deba ser accesible a los clientes desde un punto de acceso conocido.
• La única instancia debería ser extensible mediante herencia y los clientes deberían ser capaces de utilizar una instancia extendida sin modificar su código.

Estructura


Participantes

Singleton

• Define una operación “instance” que permite a los clientes acceder a la única instancia
• Puede ser responsable de crear su única instancia.
  

Colaboraciones

Los clientes acceden a la instancia única a través de la operación “instance”.

El funcionamiento de este patrón es muy sencillo se podría resumir en las siguientes pasos: primero ocultar el constructor de la clase Singleton, para que los clientes no puedan crear instancias, el segundo paso; declarar en la clase Singleton una variable miembro privada que contenga la referencia a la instancia única que queremos gestionar, tercer y ultimo paso proveer en la clase Singleton una función o propiedad que brinde acceso a la única instancia gestionada por el Singleton. Los clientes acceden a la instancia a través de esta función o propiedad.

Estos pasos se cumplen en todas las implementaciones del Singleton, independientemente de los recaudos que deban tomarse para soportar la correcta ejecución en entornos multihilo.

Consecuencias

• Acceso controlado a la única instancia. Puede tener un control estricto sobre cómo y cuando acceden los clientes a la instancia, por ejemplo para tener un acceso centralizado a un sistema de log o un sistema de caché, de forma que desde cualquier punto de la aplicación en el que queramos utilizar estos recursos, podamos garantizar que accedamos siempre a la misma instancia.
• Espacio de nombres reducido (no se requieren variables globales).
• Permite el refinamiento de operaciones y la representación. Se puede crear una subclase de Singleton.
• Permite un número variable de instancias. El patrón hace que sea fácil cambiar de opinión y permitir más de una instancia de la clase Singleton.
• Más flexible que las operaciones de clase (métodos estáticos).
  

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.