GRASP ( angol általános felelősségi hozzárendelési szoftvermintázatok - a felelősségek elosztásának általános mintái; van még az angol "grasp" szó - "kontroll, fogd meg" ) - az objektumorientált tervezésben használatos minták az osztályokhoz való felelősségkiosztás általános feladatainak megoldására , ill . tárgyakat .
Craig Larman Applying UML and Design Patterns [ 1] című könyve 9 ilyen mintát ír le: mindegyik segít megoldani bizonyos problémákat, amelyek mind az objektumorientált elemzésben , mind pedig szinte bármilyen szoftverfejlesztési projektben felmerülnek . Így a „GRASP” minták az objektumorientált elemzés jól dokumentált, szabványosított és időtálló elvei , és nem kísérlet arra, hogy valami alapvetően újat hozzanak létre.
A kilenc minta rövid leírása:
A sablon meghatározza a felelősségek elosztásának alapelvét:
A felelősséget az kell, aki a végrehajtáshoz szükséges információk maximumával rendelkezik – az információs szakértő .
Ez a minta a legnyilvánvalóbb és legfontosabb a kilenc közül. Ha nem veszi figyelembe, akkor spagetti kódot kap , amit nehéz megérteni.
A felelősségek lokalizálása, a sablon szerint:
Probléma: Ki a felelős valamilyen A osztályú objektum létrehozásáért?
Megoldás: Adja meg a B osztálynak az A osztályú objektumok létrehozásának felelősségét, ha B osztály:
Azt mondhatjuk, hogy a " Creator " minta az " Információs Szakértő " minta értelmezése (lásd az 1. pontot) az objektum létrehozásával összefüggésben.
A legtöbb generatív tervezési minta ilyen vagy olyan módon a „ Creator ” mintából származik, vagy arra támaszkodik .
Az „ elkötelezettség mértéke” egy elem folytonosságának mértéke más elemektől (vagy a velük kapcsolatos adatok mértéke).
A „ gyenge” elkötelezettség egy értékelési modell, amely megszabja, hogyan kell elosztani a fenntartandó felelősségeket.
„ Gyenge” összekapcsolás – a felelősségek és adatok megosztása, az osztályok kölcsönös függetlenségének biztosítása. Osztály "gyenge" hivatkozással:
A magas szintű kohézió olyan értékmodell, amelynek célja, hogy az objektumokat megfelelően fókuszálva, kezelhetően és érthetően tartsa. A magas kohéziót általában az alacsony elkötelezettség fenntartására használják. A magas kapcsolhatóság azt jelenti, hogy az elem felelősségei szorosan összefüggenek és koncentráltak. A programok osztályokra és alrendszerekre bontása egy példa a rendszer koherenciáját növelő tevékenységre.
Ezzel szemben az alacsony kapcsolódási lehetőség az, amikor egy adott elemnek túl sok nem kapcsolódó felelőssége van. Az alacsony kapcsolattal rendelkező elemek gyakran szenvednek attól, hogy nehezen érthetők, nehezen használhatók, nehezen karbantarthatók.
Egy osztály kohéziója a módszerei tárgyterületeinek fókuszát méri:
A rendszer eszköze és viselkedése:
Példa: Egy kereskedelmi rendszer adaptálása számos adóelszámolási rendszerhez biztosítható az adapterobjektumok külső interfészén keresztül (lásd még: " Adapterek " sablon).
Nem a tárgykörre jellemző , de:
A " Pure Fabrication " a szolgáltatások fogalmát tükrözi a tartományspecifikus tervezési modellben .
Példa a feladatra: Az "A" osztály eszközeinek használata nélkül adja hozzá az objektumokat az adatbázishoz .
Megoldás: Hozzon létre "B" osztályt az "A" osztályú objektumok rögzítéséhez (lásd még: " Data Access Object ").
A rendszer elemei közötti gyenge kapcsolódást (és az újrahasználat lehetőségét) egy köztes objektum közvetítőként való kijelölése biztosítja .
Példa: A Model-View-Controller architektúrában a vezérlő (eng. controller) gyengíti az adatok kapcsolatát (angol modell) a megjelenítésükkel (eng. view) .
A sablon megvédi az elemeket attól, hogy más elemek (objektumok vagy alrendszerek) megváltoztassák azáltal, hogy az interakciót egy rögzített interfésszel alakítja ki , amelyen keresztül (és csak ezen keresztül) lehetséges az elemek közötti interakció. A viselkedést csak az interfész eltérő megvalósításával lehet megváltoztatni.