GREPP

Inom objektorienterad design står GRASP för General Responsibility Assignment Software Patterns , en akronym för "GRASP (objektorienterad design General Responsibility Assignment Software Patterns)". Även om det anses vara mer än mönster i sig, är de en serie "god praxis" för rekommenderade tillämpningar inom mjukvarudesign.

Informationsexpert

Informationsexperten GRASP är den grundläggande principen för ansvarsfördelning. Det säger oss till exempel att ansvaret för skapandet av ett objekt eller implementeringen av en metod måste falla på klassen som känner till all information som behövs för att skapa det. På så sätt får vi en design med större kohesion och därmed förblir informationen inkapslad (minskad koppling).

Problem: Vilken är den allmänna principen för att tilldela ansvar till objekt?

Lösning: Tilldela informationsexperten ett ansvar.

Fördelar: Inkapsling upprätthålls, objekt använder sin egen information för att utföra sina uppgifter. Beteendet är fördelat på de klasser som innehåller den information som krävs. De är lättare att förstå och underhålla.

Skapare

Skaparmönstret hjälper oss att identifiera vem som ska vara ansvarig för skapandet (eller instansieringen ) av nya objekt eller klasser .

Den nya instansen ska skapas av klassen som:

Har den information som behövs för att utföra skapandet av objektet, eller
Använd de skapade instanserna av objektet direkt, eller
Lagrar eller hanterar flera instanser av klassen
Innehåller eller lägger till klassen.

En av konsekvenserna av att använda det här mönstret är synligheten mellan den skapade klassen och skaparklassen. En fördel är låg koppling, vilket innebär enkel underhåll och återanvändning. Instansering är en av de vanligaste aktiviteterna i ett objektorienterat system. Följaktligen är det användbart att ha en allmän princip för att tilldela skapelseansvar. Om den kartläggs väl kan designen stödja lös koppling, ökad klarhet, inkapsling och återanvändning.

Styrenhet

Kontrollmönstret är ett mönster som fungerar som en mellanhand mellan ett visst gränssnitt och algoritmen som implementerar det, på så sätt att det är den som tar emot data från användaren och den som skickar dem till de olika klasserna enl. metoden som kallas.

Detta mönster antyder att affärslogik bör separeras från presentationslagret, för att öka kodåteranvändningen och samtidigt ha mer kontroll.

Det rekommenderas att dela upp systemhändelser i så många kontroller som möjligt för att öka kohesionen och minska kopplingen.

Hög sammanhållning och låg koppling

Begreppen sammanhållning och koppling är inte närbesläktade, men det rekommenderas att ha en högre grad av sammanhållning med en lägre grad av koppling. På så sätt blir det mindre beroende och syftet med varje objekt i systemet specificeras.

Hög sammanhållning

Den talar om för oss att informationen som en klass lagrar måste vara konsekvent och måste (så långt som möjligt) vara relaterad till klassen.

Coincident Cohesion : Modulen utför flera uppgifter, utan någon relation mellan dem.
Logisk sammanhållning : Modulen utför flera relaterade uppgifter, men under körning kommer endast en av dem att utföras.
Temporal Cohesion : De uppgifter som utförs av en modul har, som det enda förhållandet, "att de måste utföras samtidigt".
Procedurmässig sammanhållning : Det enda förhållandet mellan uppgifterna i en modul är att de motsvarar en sekvens av steg som är specifika för "produkten".
Kommunikationssammanhållning : Uppgifterna motsvarar en sekvens av steg som är typiska för "produkten" och alla påverkar samma data.
Informationssammanhållning : Uppgifterna som utförs av en modul har sin egen utgångspunkt, sin oberoende kodning och arbetar på samma data. Typiskt exempel: OBJEKT
Funktionell sammanhållning : När modulen utför en och endast en uppgift, med ett enda mål att uppfylla, sägs den ha funktionell sammanhållning.

Låg koppling

Det är tanken att klasserna ska vara så mindre kopplade till varandra som möjligt. På ett sådant sätt att i händelse av en ändring i någon av dem, blir det minsta möjliga påverkan på resten av klasserna, vilket främjar återanvändning och minskar beroendet mellan klasserna.

Innehållskoppling : När en modul direkt refererar till innehållet i en annan modul. (På högnivåspråk är det mycket sällsynt)
Gemensam koppling : När två moduler får åtkomst till (och påverkar) samma globala värde.
Styrkoppling : När en modul skickar ett styrelement till ett annat som bestämmer dess exekveringslogik.

Polymorfism

Närhelst du måste utföra ett typberoende ansvar måste du använda dig av polymorfism , när alternativen eller relaterade beteenden varierar beroende på typ (klass), tilldela ansvaret för beteendet - med hjälp av polymorfa operationer - till de typer för vilka beteendet varierar. Tilldela samma namn till tjänster på olika objekt.

Ren tillverkning

Ren tillverkning sker i klasser som inte representerar en verklig enhet eller objekt i problemdomänen, utan är avsiktligt skapade för att minska koppling, öka kohesion och/eller förbättra kodåteranvändning. Det är lösningen när designern stöter på en lös klass och inte har någon annan klass att implementera vissa metoder i. Det vill säga att det är en "uppfunnen" klass eller att den inte finns i problemet, men genom att lägga till det förbättras systemet strukturellt. Som en kontraindikation bör vi nämna att när man missbrukar detta mönster, dyker det vanligtvis upp funktions- eller algoritmklasser (som bara har en metod).

Inriktning

Inriktningsmönstret tillåter oss att sänka kopplingen mellan två klasser genom att tilldela ansvaret för medlingen mellan dem till ett tredje mellanelement (klass). Till exempel, i en POS (Point of Sale Terminal) använd ett gränssnitt "Adapter" genom vilket vi, med de klasser som utför det, kan fastställa de olika betalningsmetoderna.

Problem: Var ska man fördela ansvar för att undvika/minska direkt koppling mellan element och förbättra återanvändningen?
Lösning: Tilldela ansvaret till ett objekt som förmedlar mellan elementen.

Skyddade varianter

Det är den grundläggande principen för att skydda dig själv från förändring, på ett sådant sätt att allt som vi förutser i en tidigare analys som är känsligt för modifieringar, vi lindar in det i ett gränssnitt, använder polymorfism för att skapa flera implementeringar och tillåta framtida implementeringar, så att det som förblir minst möjligt kopplat till vårt system, så att när variationen inträffar har det minsta möjliga inverkan på oss. Det är en del av de avancerade Grasp-mönstren.