Continuando con la serie de posts sobre los principios y patrones de diseño del software llegamos a los básicos patrones GRASP. Estos patrones GRASP significan según sus siglas en inglés General Responsability Assignment Software Patterns, es decir, patrones generales de asignación de responsabilidades.
Estos patrones GRASP se utilizan en la programación orientada a objetos, con lo que el punto de partida para aplicarlos siempre será usar POO. Cómo definir estos objetos/clases será la aplicación de cada patrón. Al grano..
Experto en información
Este patrón implica que cada objeto es responsable de almacenar su propia información, no la de los demás conceptos.
Por ejemplo, si tenemos una venta que tiene varias líneas de venta, en cada línea de venta tendremos la información exacta sobre la cantidad de producto en dicha línea, no en el objeto que representa la venta.
Creador
Este patrón implica que un objeto debe responsabilizarse de crear otros:
- Si contiene o agrega varios objetos del tipo de los creados.
- Si se encarga de registrar objetos del tipo de los creados.
- Si utiliza mucho los objetos creados.
- O si contiene los datos para crear los del tipo creados.
Por ejemplo, siguiendo con las ventas, a cada objeto venta, le podríamos asignar la responsabilidad de crear las líneas de venta porque están contenidas dentro de cada venta.
Alta cohesión
La alta cohesión la tiene un objeto si todo lo que hace está bien delimitado dentro del mismo objeto. Además, para tener alta cohesión, debe de ser un objeto cuanto más pequeño mejor.
Este concepto está relacionado inversamente con el acoplamiento, es decir, si aumenta la cohesión, suele disminuir el acoplamiento, y viceversa.
Por ejemplo, podríamos unir los conceptos de venta y linea de venta, aumentando la cohesión. No hay una solución única para cada escenario, habrá que decidir.
Bajo acoplamiento
El acoplamiento entre objetos se refiere a cuánta relación tienen los objetos entre sí. Por ejemplo, si para calcular el total de una Venta, tenemos que recorrer las LineaDeVenta, entonces aumentamos el acoplamiento entre Venta y LineaDeVenta.
Pero si no lo hacemos la alternativa es almacenar el total en Venta, y actualizarlo con cada cambio en LineaDeVenta.
De nuevo, tampoco hay una solución única para cada caso, habrá que decidir sobre la marcha.
Polimorfismo
Hay que establecer objetos generales que pueden tener varias formas. Agrupando así la cantidad de funcionalidades que tendremos repartidas entre los objetos. Es decir, supongamos que trabajamos con vehículos que pueden ser de varios tipos:
Entonces, si tenemos que programar funcionalidades distintas para los objetos de tipo coche, moto o camión, tendremos que dividir antes el objeto vehículo, en sus varias formas, programando en cada forma lo que corresponda.
Indirección
Consiste en meter objetos intermedios para independizar todos los objetos entre sí.
Por ejemplo, si estamos trabajando con formas de almacenar información, lo ideal es independizar la forma en la que almacenamos dicha información metiendo en medio una clase intermedia:
De esta forma, la clase Cliente usará objetos de tipo IAdaptador, sin que necesite saber si está almacenando datos en Mysql, Mongodb o Redis. También luego el añadir nuevos adaptadores es más fácil y no cambiará la programación en la clase Cliente.
Controlador
Es un patrón por el cual definimos objetos llamados controladores que independizan las interfaces con las acciones que haya que hacer.
Estos controladores tienen que ser lo más pequeños posible y numerosos, aislando todo lo posible las capas internas de los programas de las interfaces.
Fabricación pura
Mediante la fabricación pura, simplemente creamos objetos artificiales en el software, para mejorar el mantenimiento. También para aumentar la cohesión y bajar el acoplamiento de todos los componentes.
Esto se usa por ejemplo al crear los controladores anteriores, al hacer interfaces para los adaptadores, etcétera. Todos los objetos que no se corresponden con conceptos del mundo real, son de fabricación puramente software.
Variaciones protegidas
Finalmente, mediante la protección de las variaciones, lo que hacemos es proteger la información dentro de los objetos, para que no se puedan modificar desde otros objetos sin control. De igual manera mediante los métodos anteriores se establecen circuitos en la información añadiendo más objetos intermedios que protegerán también.
Es decir, estableceremos objetos y métodos de entrada para las modificaciones de la información, pudiendo controlar entonces, en dichos objetos intermedios y métodos, si las modificaciones tienen que hacer algo más.
Por ejemplo, esto es lo que hace meter los controladores anteriores, interfaces para los adaptadores anteriores, registros que se encarguen de crear/modificar/listar/borrar otros objetos, etcétera..
Terminando
Este post es un poco introducción a los patrones GoF de la serie de resúmenes sobre principios y patrones del diseño software.
Bibliografía
Internet, C. Martin, GoF, Craig Larman, Wikipedia y otras fuentes varias..
