De la época en que estuve mucho tiempo, y muchas horas, metido en proyectos profesionales relacionados con Orientación a Objetos y Diseño, aún guardo con esmero ciertos apuntes, reglas, etc., que me fueron de gran utilidad. Fueron tiempos duros, de muchos sótanos, pero de los que tengo un buen recuerdo y leciones aprendidas para siempre.
En ocasiones ya os he dejado, por si igualmente os fueran de utilidad, algunos de esos “apuntes”, como aquella Introducción a los patrones de diseño, una presentación o lo mejor que puedes leer para aprender diseño orientado a objetos (mi top 3 de libros).
En este caso os quiero dejar mis apuntes sobre los GRASP.
Fue un tal Larman quien los que denominó patrones GRASP (General Responsibility Assignment Software Patterns) y su utilidad viene a la hora de caracterizar objetos y clases. Saber dónde ubicar una responsabilidad (un servicio), quién es responsable de crear objetos, manejar eventos, etc.
Bueno, mejor te dejo el catálogo que leyéndolo te va a quedar más claro.
Experto
¿Quién es responsable?
Asignar una responsabilidad al experto, clase que tiene la información para poder realizarla.
Creador
¿Quién crea?
Asignar a la clase B la responsabilidad de crear instancias de A si se cumple alguno de los siguientes:
B contiene a A
B agrega a A
B tiene los datos de inicialización de A
B registra A
B usa muy cercanamente a A
Controlador
¿Quién maneja los eventos de un sistema?
Asignar la responsabilidad de manejar los eventos de un sistema a una clase que represente alguna de estas opciones:
El negocio o la organización en global (un controlador fachada).
El sistema (un controlador fachada).
Un objeto del dominio (controlador de rol).
Una clase artificial (fabricación pura) representado el uso (un controlador de caso de uso).
Bajo Acoplamiento
¿Cómo soportar baja dependencia e incremento de la reutilización?
Asignar responsabilidades que mantengan un bajo acoplamiento
Alta Cohesión
¿Cómo mantener una complejidad manejable?
Asignar responsabilidades que mantengan una alta cohesión.
Polimorfismo
¿Cuándo el comportamiento varía por tipo?
Cuando alternativas o comportamientos relacionados varían por tipo (clase), asignando responsabilidad por comportamiento, operaciones polimórficas, a los tipos para los cuales el comportamiento varía.
Fabricación Pura
¿Cómo en ocasiones se puede no violar la alta cohesión y bajo acoplamiento?
Asignando un conjunto altamente cohesivo de responsabilidades a una clase artificial que no representa algo en el dominio del problema, para soportar alta cohesión, bajo acoplamiento y reutilización.
Indirección
¿Cómo evitar el acoplamiento directo?
Asignar la responsabilidad a un intermediario que medie entre componentes o servicios.
No hablar con extraños o Ley de Demeter
Recuerda que hace poco escribimos un post sobre este tema, aquello de La Ley de Demeter, la que casi nadie aplica ¿Es bueno hacer muchas llamadas encadenadas a métodos?
¿Cómo evitar tener conocimiento de la estructura de objetos indirectos?
Asignar la responsabilidad de colaborar con un objeto indirecto a los clientes directos de los objetos, para que los clientes no necesiten conocer al objeto indirecto. Dentro de un método sólo pueden enviarse mensajes a los siguientes objetos:
A otro servicio del mismo objeto.
A un parámetro del método.
A un atributo de sí mismo.
A un elemento de una colección el cual es un atributo en sí mismo.
A un objeto creado dentro del método.
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Más allá del Management 3.0: 12 prácticas (de muchas) que no están en M 3.0 - 25 enero, 2024
- Más allá del Management 3.0: Otros muchos patrones para equipos Ágiles - 18 enero, 2024
- Años 30, Ohio (EE.UU.) y el Agile Product Management - 11 enero, 2024
Muy interesante, curiosamente tengo la impresión q últimamente se tiene en mente más el SOLID, mientras q GRASP y GoF a veces hasta se desconocen, así q un post muy relevante