Mes: febrero 2014

Patrones Estructurales (I): Patrón Adapter (Wrapper)


Objetivo:

Convertir la interfaz de una clase en otra interfaz que el cliente espera. Adapter consigue que trabajen juntas clases que de otro modo no podrían.

Design Patterns: Elements of Reusable Object-Oriented Software

El patrón Adapter nos abre el camino hacia el segundo grupo de patrones propuestos por el Gang of Four: los patrones estructurales. Si bien los patrones de creación definían la forma en la que los objetos son instanciados, los patrones estructurales se basan en la forma en la que un conjunto de clases se relacionan entre sí para proporcionar una funcionalidad compleja, proporcionando una estructura para conseguir lograr ese objetivo.

La filosofía de Adapter, al igual que vimos con Prototype, es tan simple como autoexplicativa: establecer una capa intermedia que permita comunicarse a dos clases que de otro modo no podrían hacerlo, realizando una adaptación de la interfaz de la clase que proporciona el servicio a la que la solicita.

(más…)

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…)

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…)