GREPP

Den aktuella versionen av sidan har ännu inte granskats av erfarna bidragsgivare och kan skilja sig väsentligt från versionen som granskades den 29 december 2015; kontroller kräver 84 redigeringar .

GRASP ( engelska  general responsibility assignment software patterns  - general patterns of distribution of responsibilities; det finns också det engelska ordet "grasp" - "control, grasp" ) - mönster som används i objektorienterad design för att lösa allmänna uppgifter att tilldela ansvar till klasser och föremål .

Craig Larmans bok Applying UML and Design Patterns [ 1] beskriver 9 sådana mönster: var och en hjälper till att lösa något problem som uppstår både i objektorienterad analys och i nästan alla programvaruutvecklingsprojekt . Sålunda är "GRASP"-mönstren väldokumenterade, standardiserade och beprövade principer för objektorienterad analys , och inte ett försök att tillföra något fundamentalt nytt.

Mallkatalog

Kort beskrivning av de nio mönstren:

1. Informationsexpert

Mallen definierar den grundläggande principen för ansvarsfördelning:

Ansvaret bör tilldelas den som äger den största delen av den information som krävs för utförande - informationsexperten .

Detta mönster är det mest uppenbara och viktigaste av de nio. Tar man inte hänsyn till det får man spagettikod , vilket är svårt att förstå.

Lokalisering av ansvar, utförs enligt mallen:

2. Skapare

Problem: Vem är ansvarig för att skapa ett objekt av någon klass A?

Lösning: Ge klass B ansvaret att skapa objekt av klass A om klass B:

Vi kan säga att " Skapare "-mönstret är en tolkning av " Informationsexpert "-mönstret (se punkt #1) i sammanhanget med objektskapande.

De flesta generativa designmönster härrör från eller förlitar sig på " Skapare "-mönstret på ett eller annat sätt.

3. Controller (Controller)

4. Låg koppling

" Grad av engagemang" är ett mått på kontinuiteten hos ett element från andra element (eller ett mått på den data den har om dem).

" Svagt" engagemang är en utvärderingsmodell som dikterar hur man fördelar de ansvarsområden som måste upprätthållas.

" Svag" länkning - fördelning av ansvar och data, vilket säkerställer klassernas ömsesidiga oberoende. Klass med "svag" länkning:

5. Hög sammanhållning

Högklassig sammanhållning är en värdemodell som syftar till att hålla objekt korrekt fokuserade, hanterbara och begripliga. Hög sammanhållning används vanligtvis för att upprätthålla lågt engagemang. Hög anslutning innebär att elementets ansvar är nära relaterade och fokuserade. Att bryta upp program i klasser och delsystem är ett exempel på en aktivitet som ökar sammanhållningen i ett system.

Omvänt är låg anslutning när ett givet element har för många orelaterade ansvarsområden. Element med låg anslutning lider ofta av att vara svåra att förstå, svåra att använda, svåra att underhålla.

Sammanhållningen i en klass är ett mått på fokus för ämnesområdena för dess metoder:

6. Polymorfism

Enheten och systemets beteende:

Exempel: Anpassning av ett kommersiellt system till en mängd olika skatteredovisningssystem kan tillhandahållas via det externa gränssnittet för adapterobjekt (se även: Mall " Adaptrar ").

7. Ren tillverkning

Inte specifikt för ämnesområdet , men:

" Pure Fabrication " speglar konceptet med tjänster i den domänspecifika designmodellen .

Uppgiftsexempel: Lägg till dess objekt till databasen utan att använda medel för klass "A" .

Lösning: Skapa klass "B" för att spela in objekt av klass "A" (se även: " Dataåtkomstobjekt ").

8. Riktning

Svagt engagemang mellan elementen i systemet (och möjligheten till återanvändning) säkerställs genom att ett mellanobjekt utses som deras mellanhand .

Exempel: I Model-View-Controller- arkitekturen försvagar styrenheten (eng. controller) engagemanget av data (eng. model) med deras presentation (eng. view) .

9. Motstånd mot förändring (skyddade variationer)

Mallen skyddar element från att ändras av andra element (objekt eller delsystem) genom att göra interaktion till ett fast gränssnitt genom vilket (och endast genom vilket) interaktion mellan element är möjlig. Beteende kan bara ändras genom att skapa en annan implementering av gränssnittet.

Se även

Länkar

  1. Larman, Craig . Tillämpa UML och mönster - tredje upplagan . [1] Arkiverad 30 juni 2003 på Wayback Machine