GRASP ( englanniksi yleiset vastuunjakoohjelmistomallit - vastuunjaon yleiset mallit; siellä on myös englanninkielinen sana "tartu" - "ohjaa, tartu" ) - malleja , joita käytetään oliosuunnittelussa yleisten vastuunjakotehtävien ratkaisemiseen luokille ja esineitä .
Craig Larmanin kirja Applying UML and Design Patterns [ 1] kuvaa 9 tällaista mallia: jokainen auttaa ratkaisemaan jonkin ongelman, joka ilmenee sekä olio-analyysissä että melkein missä tahansa ohjelmistokehitysprojektissa . Siten "GRASP"-mallit ovat hyvin dokumentoituja, standardoituja ja aika-testattuja olioanalyysin periaatteita , eivätkä yritys tuoda jotain täysin uutta.
Lyhyt kuvaus yhdeksästä mallista:
Mallissa määritellään vastuunjaon perusperiaate:
Vastuu tulee antaa sille, joka omistaa mahdollisimman paljon toteuttamiseen tarvittavaa tietoa – tietoasiantuntija .
Tämä malli on ilmeisin ja tärkein niistä yhdeksästä. Jos et ota sitä huomioon, saat spagettikoodin , jota on vaikea ymmärtää.
Vastuualueiden lokalisointi mallin mukaan:
Ongelma: Kuka on vastuussa jonkin luokan A objektin luomisesta?
Ratkaisu: Anna luokalle B vastuu luoda luokan A kohteita, jos luokka B:
Voimme sanoa, että " Luoja " -malli on tulkinta " informaatioasiantuntija " -kuviosta (katso kohta #1) objektin luomisen yhteydessä.
Useimmat generatiiviset suunnittelumallit perustuvat " Luoja "-kuvioon tai perustuvat tavalla tai toisella.
" Sitoutumisaste" on mitta , jolla mitataan elementin jatkuvuutta muista elementeistä (tai mita siitä datasta, joka sillä on niistä).
" Heikko" sitoutuminen on arviointimalli, joka sanelee, kuinka jakaa vastuut, jotka on säilytettävä.
" Heikko" linkitys - vastuiden ja tietojen jako, luokkien keskinäisen riippumattomuuden varmistaminen. Luokka "heikko" linkityksellä:
Korkealuokkainen koheesio on arvomalli, jonka tavoitteena on pitää kohteet oikein kohdistettuina, hallittavissa ja ymmärrettävissä. Korkeaa koheesiota käytetään yleensä alhaisen sitoutumisen ylläpitämiseen. Korkea liitettävyys tarkoittaa, että elementin vastuut liittyvät läheisesti ja keskittyvät. Ohjelmien jakaminen luokkiin ja alijärjestelmiin on esimerkki toiminnasta, joka lisää järjestelmän koherenssia.
Sitä vastoin alhainen liitettävyys on silloin, kun tietyllä elementillä on liian monia toisiinsa liittymättömiä vastuita. Elementit, joilla on alhainen liitettävyys, kärsivät usein siitä, että niitä on vaikea ymmärtää, käyttää ja ylläpitää.
Luokan koheesio mittaa sen menetelmien aihealueiden painopistettä:
Laite ja järjestelmän toiminta:
Esimerkki: Kaupallisen järjestelmän mukauttaminen erilaisiin verokirjanpitojärjestelmiin voidaan tarjota sovitinobjektien ulkoisen rajapinnan kautta (katso myös: Malli " Sovittimet ").
Ei erityistä aihealuetta , mutta:
" Pure Fabrication " heijastaa palvelukonseptia toimialuekohtaisessa suunnittelumallissa .
Tehtäväesimerkki: Lisää sen objektit tietokantaan käyttämättä luokan "A" keinoja .
Ratkaisu: Luo luokka "B" tallentaaksesi luokan "A" objektit (katso myös: " Data Access Object ").
Heikko kytkentä järjestelmän elementtien välillä (ja uudelleenkäyttömahdollisuus) varmistetaan nimeämällä väliobjekti niiden välittäjäksi .
Esimerkki: Model-View-Controller- arkkitehtuurissa ohjain ( eng. controller) heikentää datan sitoutumista (eng. malli) niiden esittämiseen (eng. view) .
Malli suojaa elementtejä muiden elementtien (objektien tai alijärjestelmien) muuttamiselta tekemällä vuorovaikutuksesta kiinteän rajapinnan , jonka kautta (ja vain jonka kautta) elementtien välinen vuorovaikutus on mahdollista. Käyttäytymistä voidaan muuttaa vain luomalla käyttöliittymälle erilainen toteutus.