GRASP (disseny orientat a objectes)

L'acrònim GRASP, en l'àmbit de la programació orientada a objectes, correspon a General Responsibility Assignment Software Patterns (Patrons Generals de Software per a l'Assignació de Responsabilitats)

El terme patrons GRASP, més que a patrons pròpiament dits, fa referència a una sèrie de bones pràctiques i principis fonamentals a l'hora d'assignar responsabilitats als diferents objectes i classes.

Els patrons GRASP intenten solucionar problemes recurrents a gairebé tots els projectes de desenvolupament de software. Aquestes tècniques no s'inventen per tal de crear nous mètodes de treball si no per documentar i estandarditzar principis llargament testejats i funcionals.

Patrons

Alta Cohesió

Problema

Com aconseguir que la complexitat sigui modelable.

Solució

Assignar les responsabilitats de manera que la cohesió entre classes relacionades es mantingui alta.

Mecànica

• Trobar classes amb pocs mètodes o que no tenen connexió.
• Cercar a les classes mètodes que fan massa tasques.
• Refer el disseny per tal que cada mètode faci una tasca única dins del disseny, identificable i que no hi hagi cap altre mètode que faci tasques semblants.

Baix Acoblament

Problema

Com aconseguir abaixar la dependència, disminuint l‘impacte dels canvis i incrementant la reutilització.

Solució

Assignar responsabilitats de forma que la responsabilitat entre classes relacionades sigui mínima.

Mecànica

• Trobar classes amb moltes associacions a altres classes.
• Cercar mètodes que depenen molt d'altres mètodes en altres classes. Dependències.
• Refer el disseny per tal de minimitzar aquestes dependències.

Controlador

El patró controlador és un patró que serveix com a intermediari entre una determinada interfície i l'algorisme que l'implementa, de manera que rep les dades de l'usuari i les envia a les diferents classes segons el mètode anomenat. Un controlador delega en altres objectes el treball que es necessita fer, és a dir, controla o coordina l'activitat.

Hi ha dos tipus de controladors:

• El controlador de façana: representa el sistema global, dispositiu o subsistema.
• El controlador de casos d'ús: representa un escenari de cas d'ús en el qual té lloc l'esdeveniment del sistema. S'utilitza quan els controladors de façana condueix a dissenys amb baixa cohesió o alt acoblament.

Per a la creació d'un patró controlador s'ha de seguir uns passos:

1. Mirar el domini / model de disseny i quan es té la família de classes fent el treball pertinent a alguna funció especifica, observar si manca algun facilitador.
2. Afegir una nova classe per prendre la responsabilitat de govern i que tot el codi client pugui accedir a la funcionalitat a partir d'aquesta classe.

La utilització d'aquest patró pot aportar un augment del potencial per reutilitzar les interfícies i dona un raonament sobre l'estat (seqüència de passos) dels casos d'ús.

Aquest patró suggereix que la lògica de negocis ha d'estar separada de la capa de presentació, això per augmentar la reutilització de codi i alhora tenir un major control. Es recomana dividir els esdeveniments del sistema en el major nombre de controladors per poder augmentar la cohesió i disminuir l'acoblament.

Creador

El patró creador ens ajuda a identificar qui ha de ser el responsable de la creació de nous objectes o classes. En altres paraules, assigna la responsabilitat de creació d'un objecte.

La intenció bàsica del patró és trobar un creador que necessiti connectar-se amb l'objecte creat en qualsevol moment.

Assignarem a la classe A la responsabilitat de crear una instància de la classe B si:

• A conté o agrega la classe B,
• A emmagatzema o maneja diverses instàncies de la classe B,
• A utilitza directament les instàncies de l'objecte B o
• A té la informació necessària per realitzar la creació de l'objecte B.

Per a la creació d'un patró creador s'ha de seguir uns passos:

1. Observar el domini/model de disseny i preguntar-se: qui hauria de crear aquestes classes?
2. Cercar les classes que creen, agregen...
3. Assignar responsabilitat de creació.

Utilitzar el patró creador aporta uns certs avantatges. Suporta un baix acoblament, el que suposa una facilitat de manteniment i reutilització de codi. La responsabilitat s'assigna a la classe que compleix amb els criteris i d'aquesta manera se separa la lògica de creació i l'execució actual.

Però també té contraindicacions, ja que l'operació de crear la instància pot arribar a ser molt complexa. Per a solucionar aquest problema es poden recórrer als patrons de disseny com el Factory Method o Abstract Factory.

Expert

És el principi bàsic que determina l'assignació de responsabilitats. Aquest principi estipula que la responsabilitat de creació d'un objecte o de la implementació d'un mètode ha recaure sobre la classe que coneix tota la informació necessària per dur a terme la tasca corresponent. D'aquesta manera aconseguim mantenir l'encapsulació de la informació.

Problema

Quin protocol seguim per tal d'assignar les responsabilitats als objectes?

Solució

Se li assigna la responsabilitat a l'expert en informació.

Bibliografia

• Larman, Craig. Applying UML and Patterns – An Introduction to Object-Oriented Analysis and Design and Iterative Development. 3a edició. New Jersey: Prentice Hall, 2005. ISBN 0-13-148906-2. 
• PATRONES GRASP (Patrones de Software para la asignación General de Responsabilidad).Parte II.