Patrones de diseño

Que son los Patrones de Diseño ?

Volviendo a las labores, esté será el inicio de una serie de entradas sobre los patrones de diseño, en esta ocasión vamos a ver conceptos en general para responder preguntas como por ejemplo ¿que son?, ¿cual es su aplicación en el desarrollo de software?, problemas y soluciones que brindan...........mencionaremos algunos de los patrones mas usados y daremos paso a próxima entradas con ejemplos Java....

No vamos a entrar en detalle sobre datos históricos, creadores o profundizar mucho sobre alguno de los patrones, tocaremos lo básico que debemos saber para trabajar con estos, en otros artículos intentaré dar ejemplos de cada uno..............Empecemos!!!!

¿Que Son? 

Los Patrones de diseño son herramientas para solucionar problemas de Diseño enfocados al desarrollo de software, estos patrones deben ser reusables permitiendo así que sean adaptados a diferentes problemáticas.

Cuando hablamos de problemáticas nos referimos a condiciones o problemas reiterativos en el desarrollo de software donde la solución se encuentra identificada mediante la aplicación de una serie de pasos, adaptando el sistema a una estructura definida por un patrón, garantizando que esta solución pueda ser aplicada cuantas veces sea necesario en circunstancias similares, evitando así la búsqueda de otras soluciones cuando estas ya se han dado anteriormente...

Existen 3 grupos de patrones:

• Creacionales: Giran en torno a la creación de Objetos

• Estructurales: Se enfocan en la estructura de clases y objetos que las componen

• De Comportamiento: Definen el modo en que las clases y objetos son relacionados, el comportamiento he interacción entre ellos. 

Algunos Patrones.

Vamos a ver algunos de los principales patrones de diseño, daremos una pequeña descripción en torno al problema y la solución................mas adelante realizaremos algunos ejemplos de aplicación.

Modelo Vista Controlador (MVC)

Es un patrón estructural que permite separar la información y lógica de negocio de la parte visual de la aplicación y la lógica que gestiona las relaciones y eventos del sistema. (Ver Ejemplo...)

Problema : Cuando tenemos código que no es fácilmente controlado o mantenible, debido a que tenemos muchas funcionalidades en una sola clase y principalmente cuando queremos dar una representación visual pero al tener todo centralizado no se puede realizar con eficacia.

Solución: Se aplica el MVC donde reestructuramos nuestro código fuente separándolo en 3 partes funcionales con comportamientos definidos que posteriormente son relacionadas entre si, facilitando la mantenibilidad y flexibilidad del código, estas 3 partes son el Modelo, la Vista y el Controlador.

• Modelo : Representa la información y los datos procesados por el sistema, gestionando la forma como se accede a estos y la lógica de negocio de la aplicación. 
• Controlador : Representa el puente de interacción entre el Modelo y la Vista, define la forma como se relacionan los componentes de la aplicación. 
• Vista : Es la representación del modelo mediante una interfaz gráfica de usuario, es la forma como el usuario interactúa con el sistema, permitiendo la ejecución de eventos he ingreso de información que serán procesados por el Modelo.

Observer

Es un patrón de comportamiento permite actualizar automáticamente el estado de un objeto dependiendo del estado de un objeto principal, cuando el objeto principal cambia sus objetos dependientes se actualizan.(Ver Ejemplo)

Problema : Cuando tenemos una dependencia de 1 a muchos entre objetos, y se espera que cuando el estado de un objeto cambie, todos los objetos dependientes de este también cambien de forma automática, por ejemplo se tiene una aplicación de venta de productos administrada por diferentes vendedores con diferentes aplicativos (web, escritorio, móvil), se espera que cada vez que cambie la cantidad de productos disponibles, la aplicación de cada vendedor automáticamente actualicé el modulo de ventas con los nuevos valores sin necesidad de recargar la página o actualizar manualmente el sistema para que muestre los cambios.

Solución: Se aplica el patrón observador para desacoplar la clase que contenga objetos dependientes, estableciendo relaciones entre los objetos, para esto se tiene una clase SujetoConcreto que sera el objeto principal y tendremos los objetos cliente o dependientes que serian de clase ObservadorConcreto, cuando el estado del SujetoConcreto cambia, se envía una señal a cada uno de sus Observadores y estos automaticamente cambian su estado basados en el estado del objeto principal.



Value Object (VO)

Consiste básicamente en la agrupación de datos dentro de un objeto, estos datos representan los campos de una tabla o entidad de la BD y facilitan su mantenimiento y transporte dentro del sistema. (Ejemplo con MySql)

Problema : Al momento de pasar argumentos de un objeto a un método puede ocasionar que el método reciba gran cantidad de datos pasados como parámetros, si posteriormente se requiere la modificación de uno de esos argumentos se obliga a que todos los métodos que reciban estos argumentos sean cambiados, presentándose problemas de acoplamiento y mantenibilidad.

Solución: Se crean clases que representan las tablas de la BD que utiliza el sistema, de esta manera las propiedades o atributos de la clase serán los campos de la entidad, permitiendo encapsular la información y facilitando la manera en que estos son transportados, así al momento de enviar los parámetros a un método, se envía un solo objeto que los contiene.


Data Access Object (DAO) 

Facilita y estructura el acceso a la información de una Base de Datos, separando la persistencia de objetos de la lógica de acceso a datos, brindando mayor flexibilidad ya que por ejemplo al momento de hacer un cambio en la lógica de negocio, esto seria transparente para la lógica de acceso a la información. (Ejemplo con MySql)

Problema : Se tienen diferentes implementaciones para el acceso a datos, de esta manera al cambiar el proveedor de  BD o la forma de conexión puede afectar la manera de acceder a los datos teniendo que implementar nuevamente el proceso en todos los componentes vinculados.

Solución: Se utilizan clases DAO para encapsular todos los accesos a la fuente de datos desacoplando de esta manera la lógica de negocio de la lógica de acceso a datos, estableciendo mayor organización y facilitando la mantenibilidad y extensibilidad del código fuente.


Delegate.

Permite extender y reutilizar la funcionalidad de una clase sin utilizar el mecanismo de herencia. (Ver Ejemplo)

Problema : Se requiere el acceso a atributos de otras clases pero estos no se pueden heredar, ya que el lenguaje no permite la herencia múltiple o solo se quiere acceder a cierta información de la clase (La clase A no desea todos los métodos de la clase B)

Solución: Se utiliza el patrón Delegate reemplazando la relación "Es Un" por la relación "Usa" delegando la responsabilidad de ejecutar un proceso concreto usando otro objeto con los permisos para realizarlo, esto se hace por medio de conceptos como la composición o agregación.


Abstract Factory 

Representa una fabrica de objetos, permitiendo la construcción de familias de objetos, es decir tipos de objetos con el mismo enfoque o relaciones. (Ver Ejemplo)

Problema : Se requiere la creación de diferentes grupos de objetos, sin que se especifique la forma de hacerse, el cliente (la clase que ejecute el evento de creación) que solicite el objeto no necesita saber como se creará, este proceso deberá ser transparente para el, el cliente solo requiere una instancia de alguno de los grupos de objetos disponibles.

Solución: Se utiliza el patrón Abstract Factory para independizar la manera como se crearán los objetos concretos de forma que sea independiente de la clase que los solicita, por ejemplo si queremos crear un objeto hamburguesa podemos usar el patrón para definir familias de Hamburguesas agrupándolas por hamburguesas McDonald´s, Wendy´s y Texas, sin importar el tipo siempre se creara un objeto 
hamburguesa pero con las características propias de cada grupo de familia disponible.


Singleton 

Permite la creación de una única instancia de clase permitiendo que sea global para toda la aplicación. (Ver Ejemplo)

Problema : Se debe restringir la creación de un tipo especifico de objetos a una única instancia garantizando un punto único de acceso para todo el sistema.

Solución: Se utiliza el patrón Singleton como mecanismo para limitar el numero de instancias de la clase, compartiendo la misma instancia por diferentes objetos del sistema, obteniendo una variable global para toda la aplicación.


Decorator 

Este patrón permite agregar funcionalidades o responsabilidades a objetos de forma transparente y dinámica, sin ser dependiente de la herencia en su totalidad. (Ver Ejemplo)

Problema :Cuando se quiere adherir responsabilidades o comportamientos específicos a un objeto pero de forma dinámica, es decir, permitiendo al usuario aplicar el comportamiento que desea, extendiendo funcionalidades de otras clases sin estar obligado a hacerlo mediante la herencia.

Solución: Se utiliza el patrón Decorator para adherir funcionalidades a un objeto implementando y creando relaciones con otras clases para incorporar dichas funcionalidades de forma dinámica, por ejemplo si tenemos una clase ventana, podemos usar el patrón para adherir otros comportamientos como por ejemplo darle estilos a la ventana, diferentes colores, bordes, tamaño, marco, entre otros componentes que deseamos vincular, los cuales se encuentran en diferentes clases.

 
Adapter. 

Permite la cooperación entre clases para extender sus funcionalidades a clases de diferentes tipos, que no pueden usarlas por mecanismos comunes como la herencia. (Ver Ejemplo)

Problema : Cuando se quiere utilizar una clase existente, pero su interfaz no es compatible o no esta relacionada con la clase que la va a utilizar.

Solución: Utilizando el patrón Adapter podemos relacionar clases incompatibles entre si, generando un mecanismo que permita extender su comportamiento por medio de una clase puente que sirva como interfaz entre la clase en cuestión y el resto de clases que quieran hacer uso de sus funcionalidades.

Conclusiones.

Como vimos los patrones de diseño nos permiten dar soluciones a  diferentes problemáticas comunes, algunas simples otras con mayor grado de complejidad, no siempre es necesario usar estos patrones sin embargo se recomienda su aplicación para buscar siempre un sistema mas optimo y con una arquitectura definida, cual o cuales aplicar depende de las necesidades del sistema.

Estos son algunos de los Patrones mas usados, existen muchos mas pero por cuestiones de organización y tamaño vamos a ver si se pueden exponer mas adelante, por el momento esta información nos sirve para dar un contexto base de lo que son y las posibles soluciones que brindan, en la próximas entradas trabajaremos cada uno de ellos mediante un ejemplo practico...


Referencias.

Head First Design Patterns

http://codejavu.blogspot.com.uy/2013/06/que-son-los-patrones-de-diseno.html