miércoles, 12 de abril de 2017

Curso Patrones de Diseño en Java

¿Que Son los Patrones de Diseño? 

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...
Proyecto Patrones de Diseño:

Este es un Proyecto hecho en Maven, el cual esta alojado en github, y se puede ver y ejecutar en cualquier IDE con soporte Maven (Netbeans, Eclipse, JBrain, etc), cada ejemplo con el respectivo nombre del patrón y Main de ejecución.


Nota:A continuación se da un breve resumen sobre patrones de diseño, dando al final la referencia correspondiente de la teoría.

Existen 3 grupos de patrones:
  • CreacionalesGiran en torno a la creación de Objetos
  • EstructuralesSe enfocan en la estructura de clases y objetos que las componen
  • De ComportamientoDefinen 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.
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ónSe 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.


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ónSe 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.
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ónSe 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.

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ónSe 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.


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ónSe 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.

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ónSe 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.


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ónSe 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.
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ónSe 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.

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ónUtilizando 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.

Referencias.

Head First Design Patterns

0 comentarios:

Publicar un comentario