1. Patrons GRASP
Eloi Trèmols Ubanell
4t EINF

2. Index
 Definició
 Patrons
 GRASP
◦ Information Expert
◦ Creator
◦ High Cohesion
◦ Low Coupling
◦ Controller
◦ Polymorfism
◦ Pure Fabrication
◦ Indirection
◦ Protected Variations
2

3. Definició
 Grasp (General Responsibility
Assignment Software Patterns)
 Orientat a objectes
 Són “bones pràctiques” per assignar
responsabilitats a classes i objectes
 La seva efectivitat està demostrada en
determinats dominis, podent
extrendre-les a altres
3

4. Patrons
 Són solucions a problemes concrets de
disseny orientat a objectes
 Es descriu tant el problema com les
solucions a aquest.
 Avantatges
◦ Recullen i documenten solucions existents a
determinats problemes
◦ El nom que reben cada un d’ells és per
ajudar a les comunicacions
 Desavantatges
◦ El fet de tenir varis patrons en un mateix
domini ens pot induir conflictes entre ells
4

5. GRASP
 Craig Larman introdueix al 1997 una sèrie de patrons bàsics
que anomena GRASP:
◦ Information Expert
◦ Creator
◦ High Cohesion
◦ Low Coupling
◦ Controller
◦ Polymorphism
◦ Pure Fabrication
◦ Indirection
◦ Protected Variations
 Els patrons GRASP no competeixen amb els altres patrons
existents, intenten determinar quins patrons cal aplicar en
determinades situacions
 Segons Larman, GRASP ajuda a entendre el disseny
d’objectes i aplicar un raonament de forma metòdica, racional
i entenedora.
5

6. Information Expert

7. GRASP – Information Expert
 Problema: Podem tenir centenars de
classes en un domini. Com assignem
les responsabilitats?
 Solució: es dóna la responsabilitat a
l’Information Expert. Serà la classe que
contindrà la informació necessària per
assignar responsabilitats.
7

8. GRASP – Information Expert
 Mecànica:
◦ Indicar clarament la responsabilitat
◦ Buscar quines classes tenen la informació
necessària per donar responsabilitats
◦ Determinar el model (domini o disseny)
◦ Dissenyar alguns diagrames d’interacció
o activitat
◦ Modificar el diagrama de classes
8

9. GRASP – Information Expert
 Consideracions:
◦ Què fem si trobem noves responsabilitats
a un nivell més baix?
◦ De vegades no es desitjable usar aquest
patró
9

10. GRASP – Information Expert
 Qui té la responsabilitat del càlcul d’una venta?
 Quin és el total?
 Qui s’encarrega del càlcul de cada línia de venta?
10

11. GRASP – Information Expert
 Qui té la responsabilitat del càlcul d’una
venta?
 El càlcul el fan entre les 3 classes
11

12. GRASP – Information Expert
12

13. Creator

14. GRASP – Creator
 Problema: Qui ha de crear noves
instàncies d’una classe?
 Solució: Una classe de tipus A podrà
crear una classe de tipus B si:
◦ Els objectes de tipus B són agregats a A
◦ Els objectes A contenen objectes B
◦ Els objectes A guarden instàncies d’objectes
B
◦ Quan es creen objectes B es requereixen
dades inicials d’objectes A
◦ Els objectes B fan ús dels A
14

15. GRASP – Creator
 Mecànica:
◦ Trobar quines classes són propícies a
crear-ne d’altres en el model de domini o
disseny
◦ Trobar classes que en creïn d’altres,
d’acord a les condicions que s’han
mencionat
◦ Modificar el diagrama de classes i/o
activitat
 Consideracions
◦ Podem considerar el fet de crear altres 15

16. GRASP – Creator
 Diagrama de seqüència de la
creació d’una nova línia de venta
16

17. Low Coupling

18. GRASP – Low Coupling
 Problema: Com aconseguir un bon
desacoblament entre classes, de
forma que una modificació del model
tingui un impacte mínim i es pugui
produir una major reutilització de codi
 Solució: Assignar responsabilitats de
forma que la responsabilitat entre
classes relacionades sigui mínima
18

19. GRASP – Low Coupling
 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
19

20. GRASP – Low Coupling
 Diagrama de seqüència d’afegir el
pagament d’una venta
20

21. GRASP – Low Coupling
 Diagrama de seqüència d’afegir el
pagament d’una venta
21

22. GRASP – Low Coupling
 Quin és millor???
 El que té menys herència i associació a altres
classes, a més de delegar responsabilitats.
 Per tant, l’esquema 2
22

23. High Cohesion

24. GRASP – High Cohesion
 Problema: Com aconseguim una
complexitat modelable?
 Solució: Assignar responsabilitats de
forma que la cohesió entre classes
relacionades sigui alta
24

25. GRASP – High Cohesion
 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
25

26. GRASP – High Cohesion
 Consideracions:
◦ Craig Larman defineix una sèrie de graus
per identificar el nivell de cohesió, de
baixa a molt alta
◦ En general, és preferible tenir classes
amb pocs mètodes però agrupats i
funcionals, a tenir classes amb molts
mètodes sense connexió
26

27. GRASP – High Cohesion
 Novament...Quin és millor???
 Des de la perspectiva de l’agrupació de mètodes amb
una alta funcionalitat, queda clar que és preferible
l’esquema 1
 Per tant, veiem que l’assignació de patrons no és una
ciència exacta i com la cohesió i el desacoblament són
com dues forces oposades.
27

28. Controller

29. GRASP – Controller
 Problema: Qui controla els events
que dispara un actor? Ex: iniciacions
 d’accions Assignem la responsabilitat
Solució:
a una classe controlador. Serà:
◦ Una classe que representi tot un sistema,
dispositiu o subsistema
◦ Una classe que representi un cas d’ús
◦ Crear classes que deleguin la feina a
altres
29

30. GRASP – Controller
 Consideracions:
◦ Per tal de decidir si es definirà un controlador de sistema o
bé un controlador per a un cas d’ús, be donat sovint per la
dinàmica dels patrons High Cohesion i Low Coupling
existents en el disseny.
◦ Cal evitar controladors sobrecarregats
◦ Els sistemes es divideixen habitualment en capes o nivells:
 Els objectes referents a la vista són a la capa de presentació
 Els objectes que representen la capa de negoci i funcionament de
l’aplicació es troben a la capa d’aplicació o de domini
 Els objectes que representen BDD, connexions de xarxa, ... són a
una capa inferior, la capa tècnica o d’infraestructura
 El disseny de les capes i els aspectes relacionats els duu a terme
un arquitecte de software
◦ Els controladors típicament reben peticions d’objectes de
la capa de presentació.
◦ Es pot veure doncs, com treballen sobre l’esquema MVC.
30

31. Polymorphism

32. GRASP – Polymorphism
 Problema: Com manegar alternatives
basades en el tipus? Com es pot crear
components de software endollables
(plugin)?
 Solució: Quan tenim alternatives o
comportaments que varien pel tipus
d’objecte (classe), cal assignar les
responsabilitats del comportament, usant
operacions polimòrfiques, als tipus pels
quals el comportament canvia
32

33. GRASP – Polymorphism
 Consideracions:
◦ Les operacions que usen el polimorfisme
són aquelles que treballen amb diferents
tipus de classes
◦ No comproven el tipus de l’objecte i usen
lògica condicional per dur a terme
diferents accions basades en el tipus
◦ En les implementacions s’acostuma a
usar una classe pare o bé una interfície.
És preferible l’ús d’una interfície per evitar
herències de classes
33

34. Pure Fabrication

35. GRASP – Pure Fabrication
 Problema: Quin objecte hauria de tenir la
responsabilitat, quan les solucions que
proposa Information Expert no són
apropiades i no volem afectar el Low
Coupling i High Cohesion?
 Solució: Assignar un conjunt de
responsabilitats High Cohesion a una
classe artificial o de conveniència, que no
representi un problema en el domini i
dissenyada per suportar alta cohesió, baix
acoblament i reutilització
35

36. GRASP – Pure Fabrication
 Exemple:
◦ PersistentStorage
 És quelcom que generalment està fora del
model de domini
 Generalment tampoc apuntarà un objecte de la
vida real
 Tot i això, és un exemple clar de com assignar
responsabilitats sense perdre baix acoblament
i alta cohesió.
36

37. Indirection

38. GRASP – Indirection
 Problema: A on assignem la responsabilitat
per evitar l’acoblament entre dues o més
classes? Com es poden desacoblar
objectes per tal que el Low Coupling sigui
suportat i tenir una alta reusabilitat?
 Solució: Assignar la responsabilitat a un
objecte que faci de mitjancer entre les
classes afectades per tal que es
desacoblin. Aquesta classe intermediari és
qui crea l’Indirection
38

39. GRASP – Indirection
 Consideracions:
◦ El benefici principal d’aquest patró és
reduir l’acoblament.
◦ Sovint pot passar que un intermediari
Indirection sigui un Pure Fabrication.
L’exemple anterior podria ser-ne un.
◦ Els patrons GoF Adapter, Bridge, Facade,
Observer i Mediator es poden posar com
Indirection
39

40. Protected Variations

41. GRASP – Protected
Variations
 Problema: Com podem dissenyar elements
(objectes, sistemes, subsistemes) de forma
que la seva alteració o inestabilitat no pugui
afectar a altres elements?
 Solució: Identificar punts on es poden
produir alteracions o inestabilitats. Assignar
responsabilitats per crear una interfície
estable sobre ells.
41

42. GRASP – Protected
Variations
 Consideracions:
◦ Generalment s’usen interfícies
◦ Fa ús del polimorfisme per crear varies
implementacions de les interfícies
◦ Beneficis:
 Facilitat per estendre funcionalitats
 Més baix acoblament
 Les implementacions es poden actualitzar sense
que el client es vegi afectat
 Es redueix l’impacte dels canvis
◦ És un bon exemple d’ocultació de la
informació sobre la classe.
42

43. Bibliografia
 Wikipedia
◦ http://en.wikipedia.org/wiki/GRASP_%28object-
oriented_design%29
◦ http://en.wikipedia.org/wiki/Craig_Larman
 Universitat d’Inver Hills (EEUU)
◦ http://faculty.inverhills.edu/dlevitt/CS%202000%2
0%28FP%29/GRASP%20Patterns.pdf
 Universitat de Colorado Boulder (EEUU)
◦ http://www.cs.colorado.edu/~kena/classes/5448/f
12/presentation-materials/duncan.pdf
 Blog de El Mundo Informático (Jorge
Saavedra)
◦ http://jorgesaavedra.wordpress.com/2006/08/17/
patrones-grasp-craig-larman/
43

44. Preguntes?
44