Patrones de creación (IV): Patrón Singleton


Objetivo:

“Asegurarse de que una clase tiene una única instancia, proporcionando acceso global a ella.”

Design Patterns: Elements of Reusable Object-Oriented Software

Hay clases que deben instanciarse una única vez. El acceso a un sistema de archivos, a la cola de impresión o al gestor de ventanas del sistema operativo debería realizarse por un único objeto, siendo labor de la propia clase el controlar que la instancia sea única. Por norma general, esta clase será accesible de forma global, y el proceso de instanciado no suele requerir parámetros.

Como podemos observar en el diagrama, nuestra clase Singleton constará al menos con dos métodos:

  • Un método Instance() de carácter estático (método de clase) que se encargará de instanciar la clase.
  • Un constructor privado que evitará que se creen nuevos objetos mediante new(), haciendo que el método Instance() sea el único que puede generar la instancia.

(más…)

Anuncios

Patrones de creación (III): Patrón Prototype


Objetivo:

“Especificar el tipo de objetos que se crearán utilizando una instancia prototipada y crear nuevos objetos realizando copias de ese prototipo.”

Design Patterns: Elements of Reusable Object-Oriented Software

El concepto de este patrón es simple: en lugar de crear un objeto, se clona, es decir, se realiza una copia exacta de otro objeto dado, denominado prototipo.

Entran en juego tres elementos:

  • Cliente: clase que solicita al prototipo que se clone.
  • IPrototipo: interfaz o clase abstracta que define la operación de clonado.
  • PrototipoConcreto: implementa IPrototipo y su método Clone() para proceder al clonado del objeto.

El proceso de clonado comienza instanciando una clase de forma habitual. Una vez que disponemos de una instancia funcional, el resto de instancias se generarán creando copias de la primera.

La forma de aplicar este patrón es simple:

  • Se define una interfaz que expondrá el método utilizado para realizar el clonado del objeto.
  • Las clases que realicen el clonado utilizarán este método para esta operación.

(más…)

Patrones de creación (II): Patrón Builder (Constructor)


Objetivo:

“Separar la construcción de un objeto complejo de su representación, de modo que el mismo proceso de construcción pueda crear representaciones diferentes.”

Design Patterns: Elements of Reusable Object-Oriented Software

Patrón Builder

Hablando en plata, el patrón Builder es un patrón creacional cuyo objetivo es instanciar objetos complejos que generalmente están compuestos por varios elementos y que admiten diversas configuraciones. Cuando hablamos de “construcción” nos referimos al proceso, mientras que cuando hablamos de “representación” nos estaremos refiriendo a los datos que componen el objeto. Se encargará, por tanto, de encapsular todo el proceso de generación de modo que únicamente necesite los detalles necesarios para “personalizar” el objeto, devolviendo como resultado una instancia del objeto complejo que deseamos construir. Es un patrón fuertemente ligado a otro, el patrón estructural Composite, del que hablaremos en posteriores artículos.

(más…)

Patrones de creación (I): Factory Patterns


Habíamos quedado en que los patrones creacionales o de creación eran aquellos en los que se delegaba la instanciación de un objeto en otro en lugar de recurrir a un simple new(). La pregunta que nos hacemos es: ¿por qué hacer esto? ¿Qué interés práctico puede existir en crear una clase cuya función sea instanciar otras clases pudiendo dejarle el trabajo a la clase original?

Bien, esta forma de trabajar puede ser útil en algunos escenarios, pero el principal suele involucrar el no saber qué objeto vamos a instanciar hasta el momento de la ejecución. Valiéndonos del polimorfismo podremos utilizar una interfaz para alojar una referencia a un objeto que será instanciado por un tercero en lugar de dejar que sea el propio constructor del objeto el que proporcione la instancia. Hablando en plata, pasaremos de esto:


	MotorDiesel motor = new MotorDiesel();

A esto otro:


	IMotor iMotor = MotorFactory.CreateInstance(tipoMotor);

(más…)

Patrones de Diseño


A lo largo de las próximas semanas intentaré, dentro de mis posibilidades, realizar un acercamiento a uno de los conceptos que todo ingeniero de software que se precie debe saber manejar con soltura: los patrones de diseño.

Un patrón de diseño no es más que una “receta” que trata de proporcionar una solución genérica a un problema concreto que se repite con frecuencia durante el desarrollo de software.

Para que un patrón de diseño sea considerado como tal debe cumplir una serie de requisitos, como el haber demostrado su efectividad a la hora de resolver el problema que afirma solventar y ser adaptable a cualquier entorno y tecnología, es decir, ser lo suficientemente genérico para asegurar su reutilización.

Por tanto, un patrón de diseño es un artefacto, por definición, abstracto. Sé que existe multitud de documentación al respecto, pero muchas de las explicaciones que se ofrecen se componen de un montón de terminología que, si bien es perfectamente familiar para un ingeniero experimentado, resulta terriblemente difícil de digerir para un recién iniciado en el mundo de la arquitectura y el diseño. Dicen que Einstein dijo en una ocasión que “no entiendes realmente algo a menos que seas capaz de explicárselo a tu abuela”. Pues bien, abuela, esta serie de artículos va por ti.

(más…)

Introducción a la inyección de dependencias mediante Unity


English version here

Tras una pequeña introducción a la inversión de control y a la inyección de dependencias, veremos cómo se comportan los contenedores DI en una aplicación práctica. Para ello hablaremos de Unity, desarrollado por Microsoft y perteneciente al paquete Enterprise Library.

Unity es, por tanto, un Framework de inyección de dependencias o DI Container. Puede ser descargado desde Codeplex o utilizando NuGet dentro de Visual Studio, método este último que utilizaremos en nuestro ejemplo.

Comenzaremos creando un nuevo proyecto de consola al que llamaremos, por ejemplo, UnityExample.

A continuación haremos uso de NuGet para añadir nuestra referencia a Unity. Será tan sencillo como hacer click derecho sobre las referencias del proyecto y seleccionar la opción Manage NuGet Packages…

(más…)

Inversión de Control e Inyección de Dependencias


English version here

Los conceptos de Inversión de Control e Inyección de Dependencias no son nuevos, sino que se remontan hasta finales de la década de los 80. Sin embargo, estos conceptos han comenzado a popularizarse debido a la estrecha relación que mantienen con la aparición de Frameworks como Spring en Java o Unity en .NET.

Inversión de Control

El concepto de Inversión de Control fue acuñado originalmente por Martin Fowler, diseñador del patrón MVVM (Model View View-Model). Fowler definió el concepto de forma informal denominándolo como el Principio de Hollywood, en el que, tras una audición, se le decía al actor la famosa frase de No nos llames, nosotros te llamaremos.

El principio establece una diferenciación entre el concepto de biblioteca y framework, definiendo el primero como un simple conjunto de clases, métodos y funciones que son invocadas por el flujo del programa y que posteriormente devuelven el control a éste (control normal) y el segundo como un diseño más abstracto y elaborado que se encargará, en algún momento, de invocar el código que el programador se encargue de codificar (inversión de control).

El ejemplo expuesto por Fowler no puede ser más sencillo: un control normal sería un simple programa secuencial de consola en el que el programa va solicitando datos al usuario y realizando operaciones (cálculos, visualización por pantalla) al recibir las respuestas. Un programa que aplica una inversión de control, sin embargo, se podría representar como una ventana compuesta por cajas de texto, etiquetas y botones. El Framework, en este caso, expondría un bucle de espera que detectaría la emisión de eventos, como la pulsación de un botón, momento en el cual se ejecutaría el código de usuario. El Framework invocará nuestro código en lugar de realizar la operación contraria.

(más…)