GRASP (diseño orientado a objetos)

Patrones de software de asignación de responsabilidad general (o Principios), abreviado como GRASP, es un conjunto de "nueve principios fundamentales en el diseño de objetos y la asignación de responsabilidades" publicados por primera vez por Craig Larman en su libro de 1997 Aplicación de UML y patrones.

Los diferentes patrones y principios utilizados en GRASP son controlador, creador, indirección, experto en información, bajo acoplamiento, alta cohesión, polimorfismo, variaciones protegidas y fabricación pura. Todos estos patrones resuelven algunos problemas de software comunes a muchos proyectos de desarrollo de software. Estas técnicas no se han inventado para crear nuevas formas de trabajar, sino para documentar y estandarizar mejor los principios de programación antiguos y probados en el diseño orientado a objetos.

Larman afirma que "la herramienta de diseño fundamental para el desarrollo de software es una mente bien formada en principios de diseño. No es UML ni ninguna otra tecnología". Por lo tanto, los principios GRASP son en realidad un conjunto de herramientas mentales, una ayuda de aprendizaje para ayudar en el diseño de software orientado a objetos.

En el diseño orientado a objetos, un patrón es una descripción con nombre de un problema y una solución que se puede aplicar en nuevos contextos; idealmente, un patrón nos aconseja cómo aplicar su solución en distintas circunstancias y considera las fuerzas y las compensaciones. Muchos patrones, dada una categoría específica de problema, guían la asignación de responsabilidades a los objetos.

Problema: ¿Cuál es el principio básico para asignar responsabilidades a los objetos?
Solución: Asignar la responsabilidad a la clase que tiene la información necesaria para cumplirla.

El experto en información (también conocido como experto o el principio del experto) es un principio que se utiliza para determinar dónde delegar responsabilidades, como métodos, campos calculados, etc.

Usando el principio del experto en información, un enfoque general para asignar responsabilidades es analizar una responsabilidad dada, determinar la información necesaria para cumplirla y luego determinar dónde se almacena esa información.

Esto hará que la responsabilidad recaiga en la clase que tenga más información necesaria para cumplirla.

Patrón o principio relacionado: Bajo acoplamiento, alta cohesión

La creación de objetos es una de las actividades más comunes en un sistema orientado a objetos. Cuál es la clase responsable de crear objetos es una propiedad fundamental de la relación entre objetos de clases particulares.

Problema: ¿Quién crea el objeto A?
Solución: En general, asigne a la clase B la responsabilidad de crear el objeto A si se cumple una o más de las siguientes condiciones:

• Instances of B conteniendo o agregando de forma compuesta casos A
• Instances of B casos registrados A
• Instances of B utilizar de cerca los casos A
• Instances of B la información inicial para casos de A y pasarlo a la creación.

Patrón o principio relacionado: Patrón de fábrica, acoplamiento bajo

El patrón controlador asigna la responsabilidad de gestionar los eventos del sistema a una clase que no pertenece a la interfaz de usuario y que representa el sistema en general o un escenario de caso de uso. Un objeto controlador es un objeto que no pertenece a la interfaz de usuario y que es responsable de recibir o gestionar un evento del sistema.

Problema: ¿Quién debería ser responsable de gestionar un evento de entrada del sistema?
Solución: Se debería utilizar un controlador de caso de uso para gestionar todos los eventos del sistema de un caso de uso, y se puede utilizar para más de un caso de uso. Por ejemplo, para los casos de uso Crear usuario y Eliminar usuario, se puede tener una única clase denominada UserController, en lugar de dos controladores de caso de uso independientes. Como alternativa, se podría utilizar un controlador de fachada; esto se aplica cuando el objeto con la responsabilidad de gestionar el evento representa el sistema en general o un objeto raíz.

El controlador se define como el primer objeto más allá de la capa de interfaz de usuario que recibe y coordina ("controla") una operación del sistema. El controlador debe delegar el trabajo que se debe realizar a otros objetos; coordina o controla la actividad. No debe realizar mucho trabajo por sí mismo. Se puede pensar en el controlador GRASP como parte de la capa de aplicación/servicio (suponiendo que la aplicación ha hecho una distinción explícita entre la capa de aplicación/servicio y la capa de dominio) en un sistema orientado a objetos con capas comunes en una arquitectura lógica del sistema de información.

Patrón o principio relacionado: Comando, Fachada, Capas, Fabricación pura

El patrón de indirección permite un acoplamiento bajo y reutiliza el potencial entre dos elementos asignando la responsabilidad de la mediación entre ellos a un objeto intermedio. Un ejemplo de esto es la introducción de un componente controlador para la mediación entre los datos (modelo) y su representación (vista) en el patrón modelo-vista-controlador. Esto garantiza que el acoplamiento entre ellos se mantenga bajo.

Problema: ¿Dónde asignar la responsabilidad para evitar el acoplamiento directo entre dos (o más) cosas? ¿Cómo desacoplar los objetos de modo que se admita un acoplamiento bajo y el potencial de reutilización siga siendo alto?

Solución: Asignar la responsabilidad a un objeto intermedio para que medie entre otros componentes o servicios de modo que no estén acoplados directamente.
El intermediario crea una indirección entre los demás componentes.

El acoplamiento es una medida de cuán fuertemente un elemento está conectado a, tiene conocimiento de, o depende de otros elementos. El bajo acoplamiento es un patrón evaluativo que dicta cómo asignar responsabilidades para los siguientes beneficios:

• menor dependencia entre las clases,
• cambio en una clase teniendo un menor impacto en otras clases,
• mayor potencial de reutilización.

La alta cohesión es un patrón evaluativo que intenta mantener los objetos adecuadamente enfocados, manejables y comprensibles. La alta cohesión se utiliza generalmente en apoyo del bajo acoplamiento. La alta cohesión significa que las responsabilidades de un conjunto dado de elementos están fuertemente relacionadas y altamente enfocadas en un tema bastante específico. Dividir los programas en clases y subsistemas, si se hace correctamente, es un ejemplo de actividades que aumentan las propiedades cohesivas de las clases y subsistemas nombrados. Alternativamente, la baja cohesión es una situación en la que un conjunto de elementos, por ejemplo, un subsistema, tiene demasiadas responsabilidades no relacionadas. Los subsistemas con baja cohesión entre sus elementos constituyentes a menudo sufren de ser difíciles de comprender, reutilizar, mantener y cambiar como un todo.

De acuerdo con el principio de polimorfismo, la responsabilidad de definir la variación de los comportamientos en función del tipo se asigna al tipo para el que se produce dicha variación. Esto se logra mediante operaciones polimórficas. El usuario del tipo debe utilizar operaciones polimórficas en lugar de ramificaciones explícitas basadas en el tipo.

Problema: ¿Cómo manejar alternativas basadas en el tipo? ¿Cómo crear componentes de software conectables?
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. (El polimorfismo tiene varios significados relacionados. En este contexto, significa "dar el mismo nombre a los servicios en diferentes objetos".)

El patrón de variaciones protegidas protege a los elementos de las variaciones de otros elementos (objetos, sistemas, subsistemas) envolviendo el foco de inestabilidad con una interfaz y utilizando polimorfismo para crear varias implementaciones de esta interfaz.

Problema: ¿Cómo diseñar objetos, subsistemas y sistemas de modo que las variaciones o inestabilidades en estos elementos no tengan un impacto indeseable en otros elementos?
Solución: Identificar puntos de variación o inestabilidad prevista; asignar responsabilidades para crear una interfaz estable en torno a ellos.

Una fabricación pura es una clase que no representa un concepto en el dominio del problema, especialmente diseñada para lograr un bajo acoplamiento, una alta cohesión y el potencial de reutilización que se deriva de ello (cuando una solución presentada por el patrón experto en información no lo hace). Este tipo de clase se denomina "servicio" en el diseño impulsado por el dominio.

Patrones y principios relacionados • Bajo acoplamiento. • Alta cohesión.

• Modelo de dominio anémico
• Patrón de diseño (ciencia de ordenador)
• Patrones de diseño (libro)
• SOLID (diseño orientado al objeto)