ÎNŢELEGE

În proiectarea orientată pe obiecte , GRASP înseamnă General Responsibility Assignment Software Patterns , un acronim pentru „GRASP (Object-oriented design General Responsibility Assignment Software Patterns)”. Deși se consideră că mai mult decât modele în sine, acestea reprezintă o serie de „bune practici” de aplicare recomandată în proiectarea software.

Expert în informații

Expertul în informații GRASP este principiul de bază al atribuirii responsabilităților. Ne spune, de exemplu, că responsabilitatea pentru crearea unui obiect sau implementarea unei metode trebuie să revină clasei care cunoaște toate informațiile necesare pentru a-l crea. In acest fel vom obtine un design cu o mai mare coeziune si astfel informatia ramane incapsulata (cuplarea scazuta).

Problemă: Care este principiul general de atribuire a responsabilităților obiectelor?

Soluţie: Atribuiți o responsabilitate expertului în informații.

Beneficii: Încapsularea este menținută, obiectele își folosesc propriile informații pentru a-și îndeplini sarcinile. Comportamentul este distribuit între clasele care conțin informațiile necesare. Sunt mai ușor de înțeles și de întreținut.

Creator

Modelul creator ne ajută să identificăm cine ar trebui să fie responsabil pentru crearea (sau instanțierea ) de noi obiecte sau clase .

Noua instanță ar trebui creată de clasa care:

Are informațiile necesare pentru a realiza crearea obiectului, sau
Utilizați direct instanțele create ale obiectului sau
Stochează sau gestionează mai multe instanțe ale clasei
Conține sau adaugă clasa.

Una dintre consecințele utilizării acestui tipar este vizibilitatea dintre clasa creată și clasa creatoare. Un avantaj este cuplarea redusă, ceea ce înseamnă ușurință de întreținere și reutilizare. Instanțarea este una dintre cele mai comune activități într-un sistem orientat pe obiecte. În consecință, este util să existe un principiu general de atribuire a responsabilităților de creație. Dacă este bine mapat, designul poate suporta cuplare slabă, claritate sporită, încapsulare și reutilizare.

Controler

Modelul de controler este un model care servește ca intermediar între o anumită interfață și algoritmul care o implementează, în așa fel încât să fie cel care primește datele de la utilizator și cel care le trimite la diferitele clase conform metoda numită.

Acest model sugerează că logica de afaceri ar trebui separată de stratul de prezentare, pentru a crește reutilizarea codului și, în același timp, pentru a avea mai mult control.

Se recomandă împărțirea evenimentelor de sistem în cât mai multe controlere posibil pentru a crește coeziunea și a reduce cuplarea.

Coeziune ridicată și cuplare scăzută

Conceptele de coeziune și cuplare nu sunt strâns legate, totuși se recomandă să existe un grad mai mare de coeziune cu un grad mai scăzut de cuplare. În acest fel există mai puțină dependență și sunt specificate scopurile fiecărui obiect din sistem.

Coeziune ridicată

Ne spune că informațiile stocate de o clasă trebuie să fie consecvente și trebuie să fie (pe cât posibil) legate de clasă.

Coeziune coincidență : Modulul realizează mai multe sarcini, fără nicio relație între ele.
Coeziune logică : Modulul îndeplinește mai multe sarcini conexe, dar, în timpul execuției, doar una dintre ele va fi efectuată.
Coeziunea temporală : Sarcinile realizate de un modul au, ca unică relație, „că trebuie executate în același timp”.
Coeziunea procedurală : Singura relație între sarcinile unui modul este aceea că acestea corespund unei secvențe de pași specifici „produsului”.
Coeziunea comunicării : Sarcinile corespund unei secvențe de pași tipici „produsului” și toate afectează aceleași date.
Coeziunea informației : Sarcinile efectuate de un modul au propriul punct de plecare, codificarea lor independentă și lucrează pe aceleași date. Exemplu tipic: OBIECTE
Coeziunea Funcțională : Când modulul execută una și o singură sarcină, având de îndeplinit un singur obiectiv, se spune că are Coezivitate Funcțională.

Cuplaj scăzut

Este ideea de a avea clasele cât mai puțin legate între ele. În așa fel încât, în cazul unei modificări în oricare dintre ele, să existe cel mai mic impact posibil asupra restului claselor, promovând reutilizarea și reducând dependența dintre clase.

Cuplare de conținut : Când un modul face referire directă la conținutul altui modul. (În limbile de nivel înalt este foarte rar)
Cuplare comună : Când două module accesează (și afectează) aceeași valoare globală.
Cuplare de control : Când un modul trimite un element de control către altul care determină logica de execuție a acestuia.

Polimorfism

Ori de câte ori trebuie să îndepliniți o responsabilitate dependentă de tip, trebuie să utilizați polimorfismul , când alternativele sau comportamentele înrudite variază în funcție de tip (clasă), atribuiți responsabilitatea comportamentului - folosind operații polimorfe - tipurilor pentru care comportamentul variază. Atribuiți același nume serviciilor pe diferite obiecte.

Fabricare pură

Fabricarea pură are loc în clase care nu reprezintă o entitate sau un obiect real în domeniul problemei, dar sunt create în mod intenționat pentru a reduce cuplarea, a crește coeziunea și/sau a îmbunătăți reutilizarea codului. Este soluția atunci când designerul dă peste o clasă liberă și nu are altă clasă în care să implementeze unele metode. Adică este o clasă „inventată” sau că nu există în problemă, dar prin adăugarea ei sistemul este îmbunătățit structural. Ca contraindicație, trebuie menționat că la abuzarea de acest tipar apar de obicei clase de funcție sau algoritm (care au o singură metodă).

Indicație

Modelul de indirecție ne permite să scădem cuplarea dintre două clase, atribuind responsabilitatea medierii dintre ele unui al treilea element intermediar (clasă). De exemplu, intr-un POS (Point of Sale Terminal) folosim un „Adaptor” de Interfata prin care, cu clasele care il desfasoara, putem stabili diferitele modalitati de plata.

Problemă: Unde să atribuiți responsabilități pentru a evita/reduce cuplarea directă între elemente și pentru a îmbunătăți reutilizarea?
Soluţie: Atribuiți responsabilitatea unui obiect care mediază între elemente.

Variante protejate

Este principiul fundamental de a te proteja de schimbare, în așa fel încât tot ceea ce prevedem într-o analiză anterioară care este susceptibil de modificări, îl înfășurăm într-o interfață, folosind polimorfismul pentru a crea mai multe implementări și a permite implementări viitoare, astfel încât ceea ce rămâne cel mai puțin legat posibil de sistemul nostru, astfel încât atunci când apare variația, să aibă cel mai mic impact asupra noastră. Face parte din tiparele avansate Grasp.