Patrones de diseño

P RINCIPIOS A TENER EN CUENTA ANTES DEL DESARROLLO

Antes de mi periodo de prácticas en Glyphstock, no era consciente de algunos de los aspectos que he asimilado, en el equipo de desarrollo, durante la implementación de la aplicación y que han cambiado mi forma de pensar a la hora de programar. En este breve capítulo, se van a exponer algunos de los aspectos que se han tenido en cuenta antes del desarrollo de la aplicación, GlyphstockApp.

4.1 DRY - (Don’t repeat yourself )

Se conoce comúnmente con el acrónimo, DRY. El concepto, en sí mismo, se conoce desde hace mucho tiempo y se refiere a las partes más pequeñas de cualquier proyecto software.

Cuando se está construyendo un gran proyecto de software, generalmente el desa-rrollador puede llegar a sentirse abrumado por la complejidad general y los humanos no suelen ser buenos para manejar la complejidad; son buenos para encontrar solu-ciones creativas para problemas de un alcance específico. Una estrategia básica para reducir la complejidad es dividir un sistema en partes o módulos que son más útiles para lograr una funcionalidad específica.

El principio DRY establece que estos pequeños módulos solo pueden ser imple-mentados exactamente una vez en todo el sistema software.

4.2 Patrones de diseño

Un patrón de diseño es una forma reutilizable de resolver un problema común. Por muy específico que sea un problema al que se enfrente el desarrollador durante la implementación del software, probablemente que alguien se haya enfrentado a un problema tan similar en el pasado, que se pueda modelar de la misma manera.

Modelado se refiere a que la estructura de las clases que conforma la solución del problema puede estar ya inventada, porque se está resolviendo un problema común que otra gente ya ha solucionado antes. Si la forma de solucionar ese problema se puede extraer, explicar y reutilizar en múltiples ámbitos, entonces se está ante unpatrón de diseño de software.

Según el libroDesign Patterns: Elements of Reusable Object-Oriented Software[14], los patrones de diseño son descripciones de cómo interconectar clases y objetos de forma que puedan resolver un problema general de diseño dentro de un contexto determinado. Dicho de otra forma, son soluciones probadas y beneficiosas a problemas recurrentes que aparecen durante el diseño de un producto software. Existen tres tipos de patrones:

• Creacionales:Relativos a problemas relacionados con la creación de objetos.

• Estructurales:Relativos a problemas relacionados con las relaciones y depen-dencias estáticas entre clases y objetos.

• De Comportamiento:Relativos a problemas relacionados el comportamiento de clases y objetos en tiempo de ejecución.

Pero...¿Por qué son importantes los patrones de diseño?Los patrones de diseño, ayudan a resolver fácilmente ciertos problemas que se presentan a menudo en el diseño de software. Muchas veces, podría parecer contraproducente el uso de los patrones, ya que, aumenta el número de clases y de métodos del diseño. Sin embargo, está probado el beneficio que aporta el patrón al diseño (siempre que se usen los patrones adecuadamente) y por tanto, existen más pros que contras. Por ejemplo,el patrónStrategy, utilizado cuando se tienen varias versiones de un mismo método, hace que el desarrollador tenga que añadir una clase por cada versión del método, pero también provoca que existan menos estructuras de decisión y por tanto disminuye la complejidad del programa. Por lo tanto,se puede decir que los patrones de diseño son importantes porque ayudan a construir software más fácilmente y de mayor calidad.

4.2. Patrones de diseño

Figura 4.1: Los 23 Patrones de Diseño Software (C)Creacional (S)Estructural (B)De comportamiento

Fuente: https://www.d.umn.edu/ gshute/softeng/new/design_patterns/design_patterns.xhtml Existen unos veintitrés patrones de diseño de software. Muchos de ellos no se van a

exponer en este documento por motivos de extensión y no utilización en el desarrollo de la aplicación, pero si que se van a exponer los que se han utilizado. Los patrones de diseño de software que más se han utilizado en la aplicación, son los siguientes:

• Singleton pattern

• Factory method pattern

• Command pattern

En los subcapítulos siguientes se van a exponer los patrones utilizados.

4.2.1 El patrón de diseño:Singleton

• Propósito:Asegurar que una clase sólo tiene una instancia y proporcionar un punto global de acceso a ella.

• Motivación:Es importante que algunas clases tan solo tengan una sola instancia.

Por ejemplo, pueden haber varias impresoras en un sistema pero solo debería de existir una cola de impresión. ¿Cómo podemos asegurar que una clase tiene una sola instancia y que esa instancia es fácilmente accesible? Una buena solución, es hacer que la clase sea responsable de su instancia. La clase debe asegurarse de que no se puedan crear más instancias y debe proporcionar una forma de acceder a su instancia.

Figura 4.2: Ejemplo del patrón de diseñoSingleton Fuente: http://www.cs.unc.edu/ stotts/GOF/hires/pat3efso.htm

• Aplicabilidad:El patrónSingletonse debe usar cuando se producen los motivos siguientes,

1. Debe haber exactamente una única instancia de una clase y los clientes deben poder acceder desde un punto de acceso.

2. La instancia debería ser extensible mediante subclases y los clientes debe-rían poder usar una instancia sin modificar su código.

• Consecuencias:Los beneficios de este patrón son los siguientes,

1. Acceso controlado a la instancia:Debido a que la claseSingletonencapsula su instancia, puede tener un control de cuándo y cómo los clientes acceden a ella.

2. Reduce el número de variables:El patrónSingletonevita tener variables globales que sólo guardan instancias de clases.

3. Permite cambiar el número de instancias:Este patrón facilita que se aña-dan más instancias de la claseSingletonen caso de que ya no queramos solo una. Además, se puede controlar el número de instancias que se usan.

4.2.2 El patrón de diseño:Factory Method

• Propósito:Permite que una clase delegue en sus subclases la creación de objetos.

• Motivación:Es importante, definir una interfaz para crear un objeto, pero dejan-do en manos de las subclases la decisión de qué clase concreta instanciar. Por ejemplo, existe una tienda online donde se le ofrece al usuario tres métodos de pagos distintos: tarjeta, paypal o transferencia bancaria. La elección del método de pago siempre va a depender de la decisión en ese instante del usuario. Un buena solución, sería usar el patrónFactory Method, teniendo una interfazPago que hace al objeto que la implemente ser de tipoPago. Todos los métodos de pago, tarjeta, paypal o tranferencia bancaria serían objetos de tipoPago, ya que,

4.2. Patrones de diseño

implementaría esta interfaz. Entonces, basta con crear un objeto que simule el funcionamiento, de toda la vida, de una fábrica. Esta vez, un objeto de la clase PagoFactory que según el tipo de pago elegido, parámetro de la clase, sepa el método de pago (objeto de tipoPago) que se ha de crear y retornar. Para que el

Figura 4.3: Ejemplo del patrón de diseñoFactory Method

Fuente: http://www.dofactory.com/net/factory-method-design-pattern lector pueda relacionar con más facilidad la imagen con el ejemplo expuesto, se aclara que la interfazProductrepresenta a la interfazPago, la clase Concre-teProductrepresenta a cualquiera de los métodos de pago del ejemplo, la clase ConcreteCreatorrepresenta a la clasePagoFactory(la fábrica de tipos de pago) y la claseCreator, simplemente sería la clase que instancia el objeto que representa a la fábrica.

• Aplicabilidad:El patrónFactory Methodse debe usar cuando se tiene que crear la instancia de un objeto pero a priori no se sabe aún que tipo de objeto tiene que ser, generalmente, porque depende de alguna opción que seleccione el usuario en la aplicación o porque depende de una configuración que se hace en tiempo de despliegue de la aplicación.

• Consecuencias:Los beneficios de este patrón son los siguientes,

1. Se gana en flexibilidad, pues crear los objetos dentro de una clase con un Factory Mehodes siempre más flexible que hacerlo directamente, debido a que se elimina la necesidad de atar la aplicación a clases de productos concretos.

2. Facilita futuras ampliaciones, puesto que se ofrece a las subclases la posibi-lidad de proporcionar una versión extendida de un objeto, con sólo aplicar en losConcreteProductla misma idea delFactory Mehod.

4.2.3 El patrón de diseño:Command

• Propósito:Encapsular una solicitud u orden como un objeto, no dejando para-metrizar clientes con diferentes solicitudes.

• Motivación:A veces es necesario publicar solicitudes u ordenes a objetos sin que estos conozcan nada sobre la operación. Por ejemplo, las interfaces de usuario incluyen objetos como son los botones y menús, los cuales realizan una solicitud en respuesta a una entrada del usuario. La interfaz, no puede implementar la solicitud explícitamente en el botón o en el menú porque solo las aplicaciones que usan la interfaz saben que debería hacerse con cada objeto. El diseñador de la interfaz, como diseñador que es, no tiene forma de conocer el receptor de la solicitud o las operaciones que la llevarán a cabo.

El patrónCommand— orden — permite a los objetos de la interfaz hacer solicitu-des de objetos de una aplicación no especificada convirtiendo la solicitud en un objeto.

Este objeto puede ser almacenado y movido como otros objetos. La clave de este patrón es unaclase abstractacommandque declara una interfaz para ejecutar operaciones. Por lo tanto, ese botón que pertenece ala interfaz, la que hemos hablado anteriormente en el ejemplo,lo único que sabe es que va a tratar con un objeto de tipo comando oCommand.

Figura 4.4: Ejemplo del patrón de diseñoCommand

Fuente: http://www.hsufengko.com/blog/command-design-pattern-example

• Aplicabilidad:Use el patrónCommandcuando se produzcan los motivos si-guientes,

1. Parametrizar objetos con una acción para realizar.

2. Estructurar un sistema en torno a operaciones de alto nivel construidas en operaciones primitivas.

• Consecuencias:Los beneficios de este patrón son los siguientes,

1. Desacoplamiento del objeto que invoca la operación del que conoce como realizarla.

2. Los objetosCommandpueden ser manipulados y extendidos como cual-quier otro objeto.

3. Es fácil añadir nuevos objetosCommandporque no hace falta cambiar las clases existentes.