#dessign patterns

Este patrón permite adaptar una clase a una interfaz ya creada.

Puede sernos útil sobre todo cuando tengamos código heredado que no implemente por si solo una interfaz dada.

Veamos su estructura:

- Cliente: Clase que necesita utilizar el código de Adaptee a través de una interfaz dada.

- ITarget: Interfaz que queremos usar.

- Adaptee: Clase que contiene el código que queremos utilizar.

- Adapter: Implementa ITarget, obtieniendo de Adaptee las funcionalidades que deseamos.

Un diagrama de la wikipedia:

Implementación

ITarget

public interface IClient { /// <summary> /// Obtenemos una lista de direcciones por id del cliente /// </summary> /// <param name="id">pk del cliente</param> /// <returns>lista de direcciones de un cliente</returns> List<string> GetAddresses(int id); }

Adaptee

public class ContactAdaptee { /// <summary> /// Obtenemos una dirección por id de contacto /// </summary> /// <param name="id">pk del contacto</param> /// <returns>dirección de un contacto</returns> public string GetAddress(int id) { // creamos la direccíón (que cogeríamos de base de datos) string address = "Av. Lexington 63, New York"; return address; } }

Adapter

public class ContactAdapter: IClient { /// <summary> /// Obtenemos una lista de direcciones por id de contacto /// </summary> /// <param name="id">pk del contacto</param> /// <returns>lista de direcciones de un contacto</returns> public List<string> GetAddresses(int id) { ContactAdaptee adaptee = new ContactAdaptee(); return new List<string> { adaptee.GetAddress(id) }; } }

o bien

public class ContactAdapter: ContactAdaptee, IClient { /// <summary> /// Obtenemos una lista de direcciones por id de contacto /// </summary> /// <param name="id">pk del contacto</param> /// <returns>lista de direcciones de un contacto</returns> public List<string> GetAddresses(int id) { return new List<string>{base.GetAddress(id)}; } }

y finalmente el Client

class Program { static void Main(string[] args) { // inicializamos el adapter IClient contactAdapter = new ContactAdapter(); // obtenemos las direcciones del contacto con pk 1 List<string> addresses = contactAdapter.GetAddresses(1); } }

Y eso es todo, gracias a este patrón podemos reutilizar una clase adaptándola a una interfaz de forma muy sencilla.

Enlaces

http://es.wikipedia.org/wiki/Adapter_(patr%C3%B3n_de_dise%C3%B1o)

http://www.dofactory.com/net/adapter-design-pattern

Singleton es un patrón de diseño que restringe la instanciación de una clase a un único objeto. Esto es muy útil si queremos que un objeto coordine acciones en un sitema o bien controle un recurso físico.

Aproximaciones

public class Singleton { public static Singleton _instance; // evitamos que se puedan crear instancias private Singleton() { } public static Singleton GetInstance() { // en caso de que no haya ninguna instanciación creamos una if (_instance == null) { _instance = new Singleton(); } return _instance; } } public class Singleton { public static Singleton _instance; private Singleton() { } public static Singleton Instance { get { if (_instance == null) { _instance = new Singleton(); } return _instance; } } }

Ambas son igualmente válidas y tienen las mismas limitaciones. Su mayor ventaja es que tiene un comportamiento conocido como lazy instantiation, es decir, que la instanciación no se produce hasta que alguien pregunte por ella.

Sin embargo, la mayor desventaja es que no nos sirve para programas multihilo, pues dos hilos pueden entrar a la vez en el método get, realizar a la vez la consulta _instance == null y crear la instancia.

Para estos casos podemos realizar una instanciación estática. Marcamos la clase como sealed, de forma que otras clases no se puedan derivar de ésta y crear instancias, y le añadimos un readonly a la estática privada para que no pueda ser modificada mas que en la construcción o instanciación estática. 

Al igual que en el caso anterior tendrá un funcionamiento de tipo lazy instantiation, pues la instanciación se realizará la primera vez que la clase sea referenciada desde otra llamada.

public sealed class Singleton { private static readonly Singleton _instance = new Singleton(); private Singleton() { } public static Singleton Instance { // obtenemos la estática ya instanciada get { return _instance; } } }

La aproximación anterior sirve para la mayoría de casos, pero en otras ocasiones, cuando necesitemos retrasar la inicialización, usar un constructor que no sea el básico o realizar otras tareas antes de la inicialización, además de trabajar en multihilo, necesitamos otra solución.

public sealed class Singleton { private static volatile Singleton _instance; private static object syncRoot = new Object(); private Singleton() { } public static Singleton Instance { get { if (_instance == null) { lock (syncRoot) { if (_instance == null) _instance = new Singleton(); } } return _instance; } } }

Las dos novedades principales son la declaración volatile para la privada _instance, que sirve para asegurarnos que su asignación se completa antes de poder ser accedida, y el uso del objeto estático syncRoot con la clave lock, que usaremos para bloquear el acceso a la creación de la instancia a otros hilos de ejecución. La doble comprovación _instance == null permite no tener que realizar el bloqueo en cada get, de manera que sólo se realizará cuando _instance sea null.

Y eso es todo, si quieres una mejor y más detallada explicación sobre el patrón Singleton puedes consultar aquí.

http://msdn.microsoft.com/es-es/library/bb972272.aspx

Para escribir este artículo me he ayudado de los siguientes enlaces:

http://en.wikipedia.org/wiki/Singleton_pattern

http://www.dofactory.com/net/singleton-design-pattern

El patrón Abstract Factory nos ofrece una estructura para crear familias de objetos relacionados sin especificar explícitamente sus clases.

Se sirve de la siguiente estructura:

- Cliente: La clase que creará las factorías para que le dé instancias de los objetos que quiere obtener.

- AbstractFactory: Clase que contiene la definición de métodos de las distintas factorías, teniendo un método que cree cada uno de los objetos que queramos obtener desde el Cliente.

- ConcreteFactory: Cada una de las factorías que implementarán de distinta forma los métodos de AbstractFactory.

- AbstractProduct: Clase que declara la definición de los métodos que queramos tener en nuestros productos.

- ConcreteProduct: Cada uno de los tipos de productos que implementarán de distinta forma los métodos de AbstractProduct.

Un diagrama sacado de la Wikipedia:

Y la implementación de dicho diagrama, usando Interfaces:

Main

class Program { static void Main(string[] args) { Application OSXClient = new Application(new OSXFactory()); Application WinClient = new Application(new WinFactory()); PrintHeader(typeof(OSXFactory)); OSXClient.Run(); PrintHeader(typeof(WinFactory)); WinClient.Run(); System.Console.ReadKey(); } static void PrintHeader(Type type) { System.Diagnostics.Debug.WriteLine(String.Format("Impresión de un botón con un application que tiene una {0}", type.Name)); } }

El cliente

public class Application { private Button _button; public Application(GUIFactory factory) { _button = factory.CreateButton(); } public void Run() { _button.Paint(); } }

Este cliente podría, por ejemplo, tener n controles de tipo botón e imprimirlos uno tras otro.

GuiFactory (AbstractFactory)

public interface GUIFactory { Button CreateButton(); }

OSXFactory y WinFactory (ConcreteFactories)

public class OSXFactory : GUIFactory { public Button CreateButton() { return new OSXButton(); } } public class WinFactory : GUIFactory { public Button CreateButton() { return new WinButton(); } }

Button (AbstractProduct)

public interface Button { void Paint(); }

OSXButton y WinButton (ConcreteProducts)

public class OSXButton : Button { public void Paint() { System.Console.WriteLine("Painted OS X button"); } } public class WinButton : Button { public void Paint() { System.Console.WriteLine("Painted Windows button"); } }