jueves, 13 de junio de 2013

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



También te podría Interesar. 


¿Hay algo que quieras anexar o comentar sobre esta entrada?  no dudes en hacerlo.....y si te gustó, te invito a compartir y Suscribirte ingresando al botón "Participar en este sitio" para darte cuenta de mas entradas como esta ;)

21 comentarios:

  1. Te felicito nuevamente, muchas gracias por tus excelentes contenidos...

    Ricardo
    Venezuela.

    ResponderEliminar
  2. Hola muy interesante el tema, felicitaciones. Con respecto a los patrones de diseño tenia un duda con el patrón MVC ya que he visto en otras fuentes que esta considerado como un patrón de arquitectura y si bien es cierto patrón de diseño y arquitectura no son lo mismo originando algunas aveces confusión, estaría agradecido si pudieras aclarar ese detalle.

    Exitos.

    ResponderEliminar
    Respuestas
    1. Hola, es un tema un poquito complejo de responder sin embargo basado en lo que he investigado el MVC podría estar en las 2 categorías, ya que un diseño de arquitectura define la arquitectura del sistema y puede incluir varios patrones de diseño, en este caso el MVC puede ser aplicado, ya que nos da la libertad de vincular otros patrones dado el nivel de abstracción, y a la vez también es de diseño pues cumple con las reglas de problema y solución........todo depende el contexto en el que lo trabajemos...........espero te haya servido y gracias por comentar ;)

      Eliminar
  3. Este comentario ha sido eliminado por el autor.

    ResponderEliminar
  4. Muy practica tu forma de abordar el tema, deja al lector animado a buscar mas sobre el tema.
    Gracias por tu aporte.

    ResponderEliminar
    Respuestas
    1. Hola David, Gracias a ti por comentar, la idea es esa, procurar que los temas sean entendibles y claro, que sirvan como una base para arrancar :)................ no se si ya los viste pero cada patrón de esta entrada esta explicado en otras entradas, te invito que las visites ;).......... Saludos

      Eliminar
  5. Hola excelente post amigo, una opinión el patrón MVC, según un libro de UML que leí es considerado un patrón arquitectónico a nivel de sistema, así mismo pueden englobar una serie de patrones de diseño, los cuales son soluciones comunes a problemas comunes haciendo referencia a mecanismos que se aplican a una sociedad de clases pero mencionaste en una respuesta que el patrón MVC también puede ser un patrón de diseño, ahora en el libro de Desing Patterns dentro de los patrones de diseño considerados en la organización del catalogo no se ubica el MVC. Pienso en que depende del contexto como mencionas. Una consulta ¿como defines un Framework? muchos hablan de eso, pero no tengo una idea especifica. Disculpa si me explaye demasiado esque me gusta todo lo relacionado a la Arq. de Software. Gracias de antemano !!

    ResponderEliminar
    Respuestas
    1. Hola, si considero que mas que saber realmente en que categoria está, depende es del contexto que se maneje, ahora para responderte, para mi un framework es una herramienta con un entorno de trabajo completo para resolver algun tipo de problematica, los frameworks brindan herramientas, documentación y formas de trabajo para tener un entorno de trabajo, una estructura o modelo a seguir..... la verdad es complejo tener claro el concepto pero pues espero que te sirva un poco..... un saludo y gracias por comentar ;)

      Eliminar
  6. Hola. Muy interesante, pero tengo una duda.
    Si tengo una tabla PERSONAS, debo crear una PERSONASDAO donde estarán sus métodos.
    Mi pregunta es: Debo crear un solo archivo PersonasVO? o debo crear varios VO dependiendo de lo que necesite? como por ejemplo diferentes reportes con diferentes campos??
    (Programo e PHP / MySQL ) Y dónde hay bibliografía que hable de eso??
    Gracias

    ResponderEliminar
  7. Hola me ah servido mucho tu blog para comprender acerca de los patrones de diseño... Tendrias algun ejemplo de como implementar dos patrones de diseño de comportamiento en un caso o un solo proyecto

    ResponderEliminar
  8. Hola, me ha surgido un problema que seguro que es de fácil solución, pero no sé como hacerlo, perdón por mi ignorancia.
    Estoy comenzando en este mundo de la programación y me ha surgido lo siguiente:
    Reproduje el código del ejemplo de conexión con mysql y no tuve ningún problema, conectó perfecto con la base de datos, el problema se me plantea a la hora de hacer este nuevo ejemplo, ya que me da un error de conexión de la base de datos:Access denied for user 'root'@'localhost' (using password: NO),cree una base de datos nueva pero sigue dándome el mismo error, y el password es el mismo que antes. Muchas gracias por la ayuda y sigue así! me estas ayudando mucho a seguir avanzando!Gracias!

    ResponderEliminar
  9. hola amigo, me tomo el tiempo para darle mi gratitud y felicitarlo por su excelente contenido, siga asi :)

    ResponderEliminar

Eres libre de realizar cualquier comentario, desde que pueda ayudar con gusto lo atenderé, y si es un critica, bienvenida sea!!!