Los patrones de software de asignación de responsabilidad general (o principios ), abreviados como GRASP , son un conjunto de "nueve principios fundamentales en el diseño de objetos y la asignación de responsabilidad" [1] : 6 publicados por primera vez por Craig Larman en su libro de 1997 [ cita requerida ] 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. [2] 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 educada en los principios de diseño. No es UML ni ninguna otra tecnología". [3] : 272 Por lo tanto, los principios GRASP son realmente 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 experto o principio experto ) es un principio utilizado para determinar dónde delegar responsabilidades tales como métodos, campos calculados, etc.
Utilizando 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 conducirá a colocar la responsabilidad en la clase con la mayor información necesaria para cumplirla. [3] : 17:11
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 los 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 Bla responsabilidad de crear el objeto Asi se cumple una o más de las siguientes condiciones:
Bcontienen o agregan de forma compuesta instancias deABregistro instancias deABuso cercano instancias deABtienen la información de inicialización para las instancias de Ay la pasan en el momento de la creación. [3] : 16:16.7 Patrón o principio relacionado : Acoplamiento bajo, patrón de fábrica
El patrón de controlador asigna la responsabilidad de gestionar los 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 controlador es un objeto que no es de 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 debe 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 Create User y Delete User , se puede tener una única clase llamada UserController , en lugar de dos controladores de caso de uso independientes. Alternativamente , se utilizaría un controlador de fachada ; esto se aplica cuando el objeto con la responsabilidad de gestionar el evento representa el sistema 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 necesita realizar a otros objetos; coordina o controla la actividad. No debería realizar mucho trabajo por sí mismo. Se puede pensar en el controlador GRASP como parte de la capa de aplicación/servicio [4] (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 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 forma que no estén acoplados directamente.
El intermediario crea una indirección entre los demás componentes.
El acoplamiento es una medida de la fuerza con la que un elemento está conectado a otros elementos, tiene conocimiento de ellos o depende de ellos. El bajo acoplamiento es un patrón evaluativo que dicta cómo asignar responsabilidades para los siguientes beneficios:
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. [3] : 314–315
Según 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 (mediante 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.