¿Qué es un patrón de diseño?
Los patrones de diseño: son un conjunto de estrategias, o buenas prácticas, que pueden facilitar el trabajo en muchas situaciones a la hora de realizar una aplicación orientada a objetos.
Los patrones de diseño son la base para la búsqueda de soluciones a problemas comunes en el desarrollo de software y otros ámbitos referentes al diseño de interacción o interfaces.
El arquitecto Christopher Alexander nos dice: Cada patrón describe un problema que ocurre infinidad de veces en nuestro entorno, así como la solución al mismo, de tal modo que podemos utilizar esta solución un millón de veces más adelante sin tener que volver a pensarla otra vez.

Objetivos

–

Los patrones de diseño pretenden:

1) Proporcionar catálogos de elementos reusables en el diseño de sistemas software.
2) Evitar la reiteración en la búsqueda de soluciones a problemas ya conocidos y solucionados anteriormente.
3) Formalizar un vocabulario común entre diseñadores.
4) Estandarizar el modo en que se realiza el diseño.
5) Facilitar el aprendizaje de las nuevas generaciones de diseñadores condensando conocimiento ya existente.

Asimismo, no pretenden:

1) Imponer ciertas alternativas de diseño frente a otras.
2) Eliminar la creatividad inherente al proceso de diseño.

Ejemplos de patrones

La referencia más utilizada en el tema de los patrones de diseño es el llamado Banda de los cuatro o Gang of Four (GoF):
1) Patrones de creación: Inicialización y configuración de objetos.

2) Patrones estructurales

Separan la interfaz de la implementación. Se ocupan de cómo las clases y objetos se agrupan, para formar estructuras más grandes.

3) Patrones de comportamiento

Más que describir objetos o clases, describen la comunicación entre ellos.
Patrones de creación: *
Abstract Factory. *Builder. *Singleton, Etc.
Patrones estructurales: *
Adapter. *Bridge. *Composite, Etc.
Patrones de comportamiento: *
Visitor. *State. *Memento.

Los patrones GRASP describen los principios fundamentales de la asignación de responsabilidades a objetos, expresados en forma de patrones

-Boch y Rumbaugh definen la responsabilidad como un contrato u obligación de un tipo o clase. Las responsabilidades se relacionan con las obligaciones de un objeto respecto a su comportamiento.
Esas responsabilidades pertenecen, esencialmente, a las dos categorías siguientes:

*Conocer. *Hacer

Entre las responsabilidades de un objeto relacionadas con hacer se encuentran:
1) Hacer algo en uno mismo.
2) Iniciar una acción en otros objetos.
3) Controlar y coordinar actividades en otros objetos.
-Entre las responsabilidades de un objeto relacionadas con conocer se encuentran:
1) Estar enterado de los datos privados encapsulados.
2) Estar enterado de la existencia de objetos conexos.
3) Estar enterado de cosas que se puede derivar o calcular
Resumiendo la introducción anterior:
-Asignar correctamente las responsabilidades es muy importante en el diseño orientado a objetos.
-La asignación de responsabilidades a menudo se asignan en el momento de preparar los diagramas de interacción.
-Los patrones son parejas de problema/solución con un nombre, que codifican buenos principios y sugerencias relacionados frecuentemente con la asignación de responsabilidades.

GRASP: Experto

Problema: ¿Cuál es el principio fundamental en virtud del cual se asignan las responsabilidades en el diseño orientado a objetos?

Un modelo de clase puede definir docenas y hasta cientos de clases de software, y una aplicación tal vez requiera el cumplimiento de cientos o miles de responsabilidades.
-Si la asignación de responsabilidades se hacen de forma adecuada, los sistemas tienden a ser más fáciles de entender, mantener y ampliar, y se nos presenta la oportunidad de reutilizar los componentes en futuras aplicaciones.
Solución: Asignar una responsabilidad al experto en información: La clase que cuenta con la información necesaria para cumplir la responsabilidad.

GRASP: Creador.
-Problema: ¿Quién debería ser responsable de crear una nueva instancia de alguna clase?
–
La creación de objetos es una de las actividades más frecuentes en un sistema orientado a objetos. En consecuencia, conviene contar con un principio general para asignar las responsabilidades concernientes a ella.
-El diseño, bien asignado, puede soportar un bajo acoplamiento, una mayor claridad, el encapsulamiento y la reutilización.
Solución: Asignarle a la clase B la responsabilidad de crear una instancia de clase A en uno de los siguientes casos:
1)
B agrega los objetos de A.
2)B contiene los objetos de A.
3)B registra las instancias de los objetos A.
4)B utiliza específicamente los objetos A.
5)B tiene los datos de inicialización que serán transmitidos a A cuando este objeto sea creado (así que B es un Experto respecto a la creación de A).

GRASP: Bajo acoplamiento

Problema: ¿Cómo dar soporte a una dependencia escasa y a un aumento de la reutilización?

El acoplamiento es una medida de la fuerza con que una clase está conectada a otras clases, con que las conoce y con que recurre a ellas

-Una clase con bajo acoplamiento no depende de muchas otras clases.
–
Una clase con alto acoplamiento recurre a muchas otras clases.

Este tipo de clases no es conveniente

Presentan los siguientes problemas:
1) Los cambios de las clases afines ocasionan cambios locales.
2) Son más difíciles de entender cuando están aisladas.
3) Son más difíciles de reutilizar porque se requiere la presencia de otras clases de las que dependen.

Solución: Asignar una responsabilidad para mantener bajo acoplamiento.
GRASP: Alta cohesión
-Problema: ¿Cómo mantener la complejidad dentro de límites manejables?
–
En la perspectiva del diseño orientado a objetos, la cohesión es una medida de cuán relacionadas y enfocadas están las responsabilidades de una clase.

-Una alta cohesión caracteriza a las clases con responsabilidades estrechamente relacionadas que no realicen un trabajo enorme.

Una clase con baja cohesión hace muchas cosas no afines o un trabajo excesivo.


No conviene este tipo de clases pues presentan los siguientes problemas:
1)Son difíciles de comprender.
2)Son difíciles de reutilizar.
3)Son difíciles de conservar.
4)Son delicadas: las afectan constantemente los cambios.

-Solución: Asignar una responsabilidad de modo que la cohesión siga siendo alta.
GRASP: Controlador.
-Problema: ¿Quién debería encargarse de atender un evento del sistema?

Un evento del sistema es un evento de alto nivel generado por un actor externo;
Es un evento de entrada externa.
Se asocia a operaciones del sistema: las que emite en respuesta a los eventos del sistema.

Un controlador: es un objeto de interfaz no destinada al usuario que se encarga de manejar un evento del sistema. Define además método de su operación

Solución: Asignar la responsabilidad del manejo de un mensaje de los eventos de un sistema a una clase que represente una de las siguientes opciones:
1)
El sistema global (controlador de fachada).
2)La empresa u organización global (controlador de fachada).
3)Algo en el mundo real que es activo (Por ejemplo, el papel de una persona) y que pueda participar en una tarea (controlador de tareas).
4)Un manejador artificial de todos los eventos del sistema de un caso de uso, generalmente denominados Manejador (Controlador de casos de uso).
Cuando No utilizar patrones de diseño
1)
La primera regla de los patrones de diseño coincide con la primera regla de la optimización:

Retrasar

Del mismo modo que no es aconsejable optimizar prematuramente, no se deben utilizar patrones de diseño antes de tiempo.
2)Seguramente sea mejor implementar algo primero y asegurarse de que funciona, para luego utilizar el patrón de diseño para mejorar las flaquezas; esto es cierto, sobre todo, cuando aún no ha identificado todos los detalles del proyecto.

Etiquetas: Cuales son las etapas de un diseño orientado a objetos, Diagramas que soporta la capa de diseño de responsabilidad diseño orientado a objetos, Ejemplo de reiteracion, Patrones diseño chuleta, Patrones grasp controlador, Reiteracion ejemplos