GRASP (General Responsibility Assignment Software Patterns) es un acrónico creado por Craig Larman, que engloba nueve principios de diseño orientado a objetos.
Traducción de algunas páginas del Libro Applying UML and Patterns – An Introduction to Object-Oriented Analysis and Design and Iterative Development – Craig Larman
[…] Son guías sistemáticas para la asignación de responsabilidades a las clases y métodos [Wikipedia]. Estas guías no están relacionadas con los principios de diseño SOLID. […]
The critical design tool for software development is a mind well educated in design principles (Craig Larman) pag 6.
Patrones de diseño
Los patrones de diseño comunican las \»mejores prácticas\» que los expertos en diseño orientados a objetos aplican para crear sistemas (pag XVII)
Responsabilidades y Métodos
Pag 216-217
UML define una responsabilidad como \»un contrato u obligación de un clasificador\». Las responsabilidades están relacionadas con las obligaciones de un objeto en términos de su comportamiento. Básicamente, estas responsabilidades son de los dos tipos siguientes:
- Hacer
- hacer algo por sí mismo, como crear un objeto o realizar un cálculo
- iniciar la acción en otros objetos
- controlar y coordinar actividades en otros objetos
- Saber
- saber acerca de los datos encapsulados privados
- saber acerca de objetos relacionados
- saber acerca de las cosas que puede derivar o calcular
Las responsabilidades se asignan a clases de objetos durante el diseño de objetos. Por ejemplo, puedo declarar que \»una Venta es responsable de crear ItemsLineaVenta\» (responsabilidad tipo hacer), o \»Una Venta es responsable de conocer su total\» (responsabilidad tipo saber). Las responsabilidades relevantes relacionadas con \»saber\» a menudo son inferibles del modelo de dominio, debido a los atributos y asociaciones que ilustra.
La traducción de responsabilidades en clases y métodos está influenciada por la granularidad de la responsabilidad. La responsabilidad de \»proporcionar acceso a bases de datos relacionales\» puede implicar docenas de clases y cientos de métodos, empaquetados en un subsistema. Por el contrario, la responsabilidad de \»crear una Venta\» puede implicar sólo uno o pocos métodos.
Una responsabilidad no es lo mismo que un método, pero los métodos se implementan para cumplir con las responsabilidades. Las responsabilidades se implementan mediante métodos que actúan solos o colaboran con otros métodos y objetos. Para por ejemplo, la clase Venta podría definir uno o varios métodos para conocer su total; mediante, un método denominado getTotal. Para cumplir con esa responsabilidad, la Venta puede colaborar con otros objetos, como el envío de un mensaje a getSubtotal a cada ItemsLineaVenta objeto pidiendo su subtotal.
En la construcción de software se deben elegir adecuadamente las clases, objetos y la interacción entre ellas, para lograr que el código permita la refactorización. La calidad del diseño del código está relacionado con la habilidad para aplicar estos nueve principios.
Design and Iterative Development – Craig Larman
Patrones Grasp
Patrones básicos
Por favor, estudie los siguientes patrones. Más tarde, aprenda los patrones restantes.
Pag 220
- Experto en información
- Creador
- Alta cohesión
- Bajo acoplamiento
- Controlador
Patrones restantes
- Polimorfismo
- Indirección
- Fabricación pura
- Variaciones Protegidas
| Patrón | Descripción |
| Experto en información | ¿Un principio general de diseño de objetos y asignación de responsabilidades? Asigne una responsabilidad al experto en información— la clase que tenga la información necesaria para cumplir con la responsabilidad |
| Creador | ¿Quién crea? (Tenga en cuenta que Factory es una solución alternativa común.) Asigne a la clase B la responsabilidad de crear una instancia de la clase A si una de estas condiciones es verdadera: 1. B contiene A 2. B agrega A 3. B tiene los datos de inicialización de A 4. B registra A 5. B utiliza de cerca A |
| Alta cohesión | ¿Cómo mantener la complejidad manejable? Asignar responsabilidades para que la cohesión siga siendo alta |
| Bajo acoplamiento | ¿Cómo soportar la baja dependencia e incrementar la reutilización? Asigne responsabilidades para que el acoplamiento (innecesario) siga siendo bajo |
| Controlador | ¿Quién maneja un evento del sistema? Asigne la responsabilidad de controlar un mensaje de evento del sistema a una clase que represente uno de estas opciones: 1. Representa el sistema general, el dispositivo o un subsistema (controlador de fachada). 2. Representa un escenario de caso de uso en el que se produce el evento del sistema (caso de uso o sesión controlador) |
| Polimorfismo | ¿Quién es responsable cuando el comportamiento varía según el tipo? Cuando las alternativas o comportamientos relacionados varían según el tipo (clase), asigne la responsabilidad del comportamiento —mediante operaciones polimórficas— a los tipos para los que varía el comportamiento. |
| Indirección | ¿Cómo asignar responsabilidades para evitar el acoplamiento directo? Asigne la responsabilidad a un objeto intermedio para mediar entre otros componentes o servicios, para que no estén directamente acoplados. |
| Fabricación pura | ¿Quién es responsable cuando estás desesperado, y no quieres violar la alta cohesión y bajo Acoplamiento? Asigne un conjunto de responsabilidades altamente cohesionado a una clase con \»comportamiento\» artificial o conveniente que no representa un concepto del dominio del problema — algo inventado, con el fin de apoyar la alta cohesión, el bajo acoplamiento y la reutilización. |
| Variaciones Protegidas | Cómo asignar responsabilidades a objetos, subsistemas y sistemas para que las variaciones o inestabilidad en estos elementos no tengan un impacto indeseable en otros elementos? Identificar puntos de variación o inestabilidad predecibles; asignar responsabilidades para crear una \»interfaz\» estable a su alrededor. |