Patrones de Asignación de Responsabilidades

Patrones de Asignación de Responsabilidades (GRASP)
Patrones de Asignación de Responsabilidades (GRASP)




Patrones de Asignación de Responsabilidades (GRASP) Es en sistema orientado a objetos se compone de objetos que envían mensajes a otros objetos para que lleven a cabo las operaciones requeridas. Los diagramas de interacción describen gráficamente estas operaciones, a partir de los objetos en interacción, que se responsabilizan de una actividad determinada.

Experto:

  • Problema: ¿Cuál es el principio fundamental en virtud del cual se asignan las responsabilidades en el diseño orientado a objetos?
  • Solución: Asignar una responsabilidad al experto en información: la clase que cuenta con la información necesaria para cumplir la responsabilidad.
  • Explicación: Experto es un patrón que se usa más que cualquier otro al asignar responsabilidades; es un principio básico que suele utilizarse en el diseño orientado a objetos. Da origen a diseños donde el objeto de software realiza las operaciones que normalmente se aplican a la cosa real que representa, por lo que ofrece una analogía con el mundo real.
  • Beneficios: Con la utilización de este patrón se conserva el encapsulamiento, ya que los objetos se valen de su propia información para hacer lo que se les pide. El omportamiento se distribuye entre las clases que cuentan con la información requerida, alentando con ello definiciones de clases sencillas y más cohesivas que son más fáciles de comprender y mantener.

Creador:

Problema:

¿Quién debería ser responsable de crear una nueva instancia de alguna clase?

Solución:

Asignarle a la clase B la responsabilidad de crear una instancia de la clase A en uno de los siguientes casos:

  • B agrega los objetos A.
  • B contiene los objetos A.
  • B registra las instancias de los objetos A.
  • B utiliza específicamente los objetos A.
  • B tiene los datos de inicialización que serán trasmitidos a A cuando este objeto sea creado (así que B es un Experto respecto a la creación de A).
  • B es un creador de los objetos A.
  • Si existe más de una opción, prefiera la clase B que agregue o contenga la clase A.

Explicación:

El patrón Creador guía la asignación de responsabilidades relacionadas con la creación de objetos. El propósito fundamental de este patrón es encontrar un creador que se debe conectar con el objeto producido en cualquier evento.

Beneficios:

Brinda un soporte a un bajo acoplamiento –patrón que será descrito más adelante– lo que supone menos dependencias respecto al mantenimiento y mejores oportunidades de reutilización.

Bajo Acoplamiento.

Problema:

¿Cómo dar soporte a una dependencia escasa y aun 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 (o débil) acoplamiento no depende de muchas otras clases. Una clase con alto (o fuerte) acoplamiento recurre a muchas otras. Este tipo de clases no es conveniente, ya que presentan los siguientes problemas:

  • Los cambios de las clases afines ocasionan cambios locales.
  • Son más difíciles de entender cuando están aisladas.
  • 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.

Explicación:

El bajo acoplamiento es un principio que se debe tener siempre en cuenta durante las decisiones de diseño. Es un patrón evaluativo que el diseñador aplica al juzgar sus decisiones de diseño. Este patrón estimula asignar una responsabilidad de modo que su colocación no incremente el acoplamiento tanto que produzca los resultados negativos propios de un alto acoplamiento. Soporta el diseño de clases más independientes, que reducen el impacto de los cambios, y también más reutilizables, que acrecienten la oportunidad de una mayor productividad. No puede considerarse en forma independiente de otros patrones como Experto o Alta cohesión, sino que más bien ha de incluirse como uno de los principios del diseño que influyen en la decisión de asignar responsabilidades.

Beneficios:

Con el uso de este patrón los componentes no se afectan por cambios de otros componentes, son fáciles de entender por separado y fáciles de reutilizar.

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 cuan 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:

  • Son difíciles de comprender.
  • Son difíciles de reutilizar.
  • Son difíciles de conservar.
  • Son delicadas: las afectan constantemente los cambios.

Las clases con baja cohesión a menudo representan un alto grado de abstracción o han asumido responsabilidades que deberían haber delegado a otros objetos.

Solución:

Asignar una responsabilidad de modo que la cohesión siga siendo alta.

Explicación:

El patrón Alta Cohesión es la meta principal que ha de tenerse en cuenta en cada momento en todas las decisiones de diseño. Es un patrón evaluativo que el desarrollador aplica al valorar sus decisiones de diseño. Una clase de alta cohesión posee un número relativamente pequeño, con una importante funcionalidad relacionada y poco trabajo que hacer. Colabora con otros objetos para compartir el esfuerzo si la tarea es grande.

Beneficios:

Con el uso de este patrón mejoran la claridad y la facilidad con que se entiende el diseño. Se simplifican el mantenimiento y las mejoras en funcionalidad. A menudo se genera un bajo acoplamiento. La ventaja de una gran funcionalidad soporta una mayor capacidad de reutilización, porque una clase muy cohesiva puede destinarse a un propósito muy específico.

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 el 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:

  • El “sistema” global (controlador de fachada).
  • La empresa u organización global (controlador de fachada).
  • Algo en el mundo real que es activo (por ejemplo, el papel de una persona) y que pueda participar en la tarea (controlador de tareas).
  • Un manejador artificial de todos los eventos del sistema de un caso de uso (controlador de casos de uso).

Utilice la misma clase de controlador con todos los eventos del sistema en el mismo caso de uso.

Explicación:

La mayor parte de los Sistemas reciben eventos de entrada externa, los cuales generalmente incluyen una interfaz gráfica para el usuario operado por una persona. Otros medios de entrada son los mensajes externos o las señales procedentes de sensores como sucede en los sistemas de control de procesos. En todos los casos, si se recurre a un diseño orientado a objetos, hay que elegir los controladores que manejen esos eventos de entrada. Este patrón ofrece una guía para tomar decisiones apropiadas que generalmente se aceptan. La misma clase controlador debería utilizarse con todos los eventos sistémicos de un caso de uso, de modo que se pueda conservar la información referente al estado del caso.

Beneficios:

Garantiza que la empresa o los procesos de dominio sean manejados por la capa de los objetos del dominio y no por la de la interfaz. Al delegar a un controlador la responsabilidad de la operación de un sistema entre las clases del dominio favorece la reutilización de la lógica para manejar los procesos afines del negocio en aplicaciones futuras.

Véase también

Fuente

Jorgesaavedra