viernes, 14 de junio de 2019

Resumen Final - Patrones GRASP - Sistemas 2

Patrones GRASP


Los patrones GRASP describen los principios fundamentales de la asignación de responsabilidades a objetos, expresados en formas de patrones.
GRASP es un acrónimo que significa General Responsibility Assignment Software Patterns. El nombre se eligió para indicar la importancia de captar estos principios, si se quiere diseñar eficazmente el software orientado a objetos.
Paso a enumerarlos junto con su definición formal:

Experto en información

Problema:

¿De qué forma podemos saber qué responsabilidad delegar a cada objeto?

Solución:

Asignar una responsabilidad al experto en información; la clase que tiene la información necesaria para llevar a cabo la responsabilidad.

Creador

Problema:

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

Solución:

Crear una nueva instancia por la clase que:

  • Tiene la información necesaria para realizar la creación del objeto
  • Usa directamente las instancias creadas del objeto
  • Almacena o maneja varias instancias de la clase
  • Contiene o agrega la clase


Controlador

Problema:

¿Quién gestiona un evento del sistema?

Solución:

Asignar la responsabilidad de gestionar un mensaje de un evento del sistema a una clase que represente una de estas dos opciones:

  1. Representa el sistema global, dispositivo o subsistema (controlador de fachada).
  2. Representa un escenario de caso de uso en el que tiene lugar el evento del sistema (controlador de caso de uso o de sesión)


Alta cohesión

Problema:

¿Cómo mantener manejable la complejidad?

Solución:

Asignar responsabilidades de manera que la información que almacena una clase sea coherente y este relacionada con la clase.

Bajo acoplamiento

Problema:

¿Cómo dar soporte a las bajas dependencias y al incremento de la reutilización?

Solución:

Diseñar con el objetivo de tener las clases lo menos ligadas entre sí que se pueda. De tal forma que en caso de producirse una modificación en alguna de ellas, se tenga la mínima repercusión posible en el resto de clases, potenciando la reutilización, y disminuyendo la dependencia entre las clases

Polimorfismo

Problema:

¿Quién es responsable cuando el comportamiento varía en función del tipo?

Solución:

Cuando las alternativas o comportamientos relacionados varían según el tipo (clase), asigne la responsabilidad del comportamiento – utilizando operaciones polimórficas – a los tipos para los que varía el comportamiento.

Fabricación Pura

Problema:

¿Quién es el responsable cuando está desesperado, y no quiere violar los principios de alta cohesión y bajo acoplamiento?

Solución:

Asignar un conjunto altamente cohesivo de responsabilidades a una clase de “comportamiento” artificial o de conveniencia que no representa un concepto del dominio del problema – algo inventado -, para dar soporte a la alta cohesión, bajo acoplamiento y la reutilización.

Indirección

Problema:

¿Cómo asignar responsabilidades para evitar el acoplamiento directo?

Solución:

Asignar la responsabilidad a un objeto intermedio para mediar entre otros componentes o servicios, de manera que no se acoplen directamente.

Variaciones Protegidas

Problema:

¿Cómo asignar responsabilidades a los objetos, subsistemas, y sistemas de manera que las variaciones o inestabilidad en estos elementos no influya de manera no deseable en otros elementos?

Solución:

Identificar los puntos de variaciones predecibles o inestabilidad; asignar las responsabilidades para crear una “interfaz” estable alrededor de ellos.



No hay comentarios.:

Publicar un comentario

Listado de cases de Bases de datos y sus temas

 Listado de clases de Sistemas de Bases de Datos Clase Clases de 02/04 Clase Clase Temas: Claves foráneas. Clase Clas...