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

/ 2. Ingeniería de Software / Por

1. Controller (Controlador)

El Patrón Controlador (controller) asigna la responsabilidad de tratar con eventos del sistema, a una clase que no es de interfaz de usuario y que representa el sistema general o un escenario de caso de uso, .

Un objeto de controlador (controller) es responsable de recibir o controlar un evento del sistema y no es un objeto de interfaz de usuario.

\"PATRON_CONTROLLER\"

Problema: ¿Que primer objeto mas allá de la capa de interfaz de usuario debe recibir y coordinar (controlar) una operación del sistema?

Solución: Asignar la responsabilidad a uno de los siguientes tipos de clases:

  • Controlador Fachada (Facade Controller). Representa todo el \»Sistema\», \»objeto raíz\» o un dispositivo en que el software esta ejecutándose.
  • Controlador de Sesión (Use case o session controller). Representa el caso de un escenario dentro del sistema donde ocurre un evento.
  • Las clases normalmente llevarán el sufijo: <UseCaseName>Handler, <UseCaseName>Coordinator, or <UseCaseName>Session

Comentarios: Un controlador no hace trabajo adicional, se guía por los grados de acoplamiento y cohesión, realiza la delegación. Por ejemplo, los objetos de interfaz de usuario no deben realizar lógica de negocios. El elemento Controller del Patrón MVC es un ejemplo de aplicación de este principio.

2. Creator (Creador)

El Patrón Creator (controller) asigna la responsabilidad de tratar con eventos del sistema, a una clase que no es de interfaz de usuario y que representa el sistema general o un escenario de caso de uso, .

Un objeto de Creator (controller) es responsable de recibir o controlar un evento del sistema y no es un objeto de interfaz de usuario.

\"patron_create\"

Problema: ¿Quien es el responsable de crear las nuevas instancias de alguna clase?

Solución: Asignar a la clase B la responsabilidad de crear una instancia de la clase A si se cumplen una o mas de las siguientes condiciones:

  • B agrega A (agregación simple, atributos compartidos)
  • B contiene A (composición: atributos no compartidos)
  • B registra instancias de objetos A
  • B utiliza estrechamente los objetos A
  • B tiene los datos de inicialización que serán enviados a A Cuando sea creado (por lo tanto B es un experto con respecto a la creación de A)

Comentarios:Este enfoque puede dar como resultado un bajo acoplamiento, mayor claridad, encapsulación y reutilización.

3. High cohesion (Alta cohesión)

¿Cómo mantener la complejidad manejable? Asignar responsabilidades para que la cohesión siga siendo alta?.

Problema: ¿Cómo mantener la complejidad manejable? En cuanto al diseño de objetos, la cohesión (la cohesión funcional) es una medida de cuán estrechamente relacionadas (strongly related)  y enfocadas (focused) están las responsabilidades de un elemento .

  • Alta cohesión. Un elemento con responsabilidades altamente relacionadas, y que no realiza mucha cantidad de trabajo, tiene una alta cohesión. Estos elementos incluyen clases, subsistemas, etc.
  • Baja cohesión. Una clase que hace muchas cosas no relacionadas, o hace mucho trabajo, tiene una baja cohesión. Este tipo de clases son indeseables; porque tienen los siguientes problemas:
    • difícil de comprender
    • difícil de reutilizar
    • difícil de mantener
    • frágil; se ve afectado constantemente por los cambios

Las clases de baja cohesión baja a menudo representan un \»grano grande\» de la abstracción, o han tomado responsabilidades que deberían haber sido delegadas a otros objetos.

Solución: Asigne una responsabilidad para que la cohesión siga siendo alta.

4. Low coupling ( Bajo acoplamiento)

Problema: ¿Cómo mantener la baja dependencia,  cambios de bajo impacto e incrementar la reutilización?

Bajo acomplamiento. Es una medida de que tan estrechamente un elemento \»está conectado para\», \»tiene conocimiento de\», o se basa en otros elementos. Un elemento con bajo (o débil) acoplamiento es \»no dependiente\» de \»muchos otros\» elementos; \»muchos otros \» depende del contexto, pero será analizado. Estos elementos incluyen clases, subsistemas, sistemas y así sucesivamente.

Alto acoplamiento. Una clase con un acoplamiento alto (o fuerte) depende de \»muchas otras\» clases. Tales clases puede ser indeseable; algunos sufren los siguientes problemas:

  • los cambios en las clases relacionadas fuerzan los cambios locales.
  • más difícil de entender aisladamente.
  • más difícil de reutilizar porque su uso requiere la presencia adicional de las clases en las que depende.

Solución: Asigne una responsabilidad para que el acoplamiento permanezca bajo.

Comentarios. El \»bajo acoplamiento\» es un principio a tener en cuenta durante todas las decisiones de diseño; es un objetivo subyacente de considerar continuamente. Es un principio evaluativo que un diseñador aplica mientras evalúa todas las decisiones de diseño.

  • Low coupling ( Bajo acoplamiento)
  • Information expert (Experto en Información)
  • Polymorphism (Polimorfismo)
  • Protected variations (Variaciones protegidas)
  • Pure fabrication (Fabricación pura)
  • Indirection (Indirección)

Fuentes consultadas:

Páginas: 1 2