Ansvarsdrevet design - Responsibility-driven design

Ansvarsstyret design er en designteknik i objektorienteret programmering , som forbedrer indkapsling ved hjælp af klient-servermodellen . Det fokuserer på kontrakten ved at overveje de handlinger, som objektet er ansvarlig for, og de oplysninger, som objektet deler. Det blev foreslået af Rebecca Wirfs-Brock og Brian Wilkerson.

Ansvarsstyret design er i direkte kontrast til datadrevet design, som fremmer definitionen af ​​en klasses adfærd sammen med de data, den har. Datadrevet design er ikke det samme som datadrevet programmering , som handler om at bruge data til at bestemme kontrolflowet , ikke klassedesign.

I den klient-server-model, de henviser til, er både klienten og serveren klasser eller forekomster af klasser. På et bestemt tidspunkt repræsenterer enten klienten eller serveren et objekt. Begge parter forpligter sig til en kontrakt og udveksler oplysninger ved at overholde den. Klienten kan kun fremsætte de anmodninger, der er specificeret i kontrakten, og serveren skal besvare disse anmodninger. Ansvarsstyret design forsøger således at undgå at håndtere detaljer, såsom den måde, hvorpå anmodninger udføres, ved i stedet kun at specificere hensigten med en bestemt anmodning. Fordelen er øget indkapsling , da specifikationen af ​​den nøjagtige måde, hvorpå en anmodning udføres, er privat for serveren.

For at fremme indkapslingen af ​​serveren opfordrer Wirfs-Brock og Wilkerson til sprogfunktioner, der begrænser indflydelse udefra til en klasses opførsel. De kræver, at synligheden af ​​medlemmer og funktioner skal være fint kornet, f.eks. I Eiffels programmeringssprog. Endnu finere kontrol af synligheden af ​​lige klasser er tilgængelig på Newspeak programmeringssprog.

Oversigt

Ansvarsstyret design fokuserer på objekterne som adfærdsmæssige abstraktioner, der er kendetegnet ved deres ansvar. Det CRC-kort modellering teknik bruges til at generere disse adfærdsmæssige abstraktioner. Resten af ​​objektstrukturen inklusive dataattributter tildeles senere, efter behov. Dette får designet til at følge hierarkiet for arv, hvilket forbedrer indkapsling og gør det lettere at identificere abstrakte klasser . Det kan også gruppere klasserne sammen baseret på deres kunder, der betragtes som en unik evne.

Et godt objektorienteret design involverer et tidligt fokus på adfærd for at realisere de muligheder, der opfylder de angivne krav, og en sen binding af implementeringsdetaljer til kravene. Denne tilgang hjælper især med at decentralisere kontrol og distribuere systemadfærd, som kan hjælpe med at styre kompleksiteten af ​​store eller distribuerede systemer med høj funktionalitet . På samme måde kan det hjælpe med at designe og vedligeholde forklaringsfaciliteter for kognitive modeller , intelligente agenter og andre videnbaserede systemer .

Byggesten

I deres bog Object Design: Roles, Responsiences and Collaborations beskriver forfatterne følgende byggesten, der udgør ansvarsstyret design.

  • Anvendelse: En softwareapplikation kaldes et sæt interagerende objekter.
  • Kandidater: Kandidater eller kandidatobjekter er nøglebegreber i form af objekter beskrevet på CRC-kort. De fungerer som indledende opfindelser i processen med objektdesign.
  • Samarbejde: Et samarbejde defineres som en interaktion mellem objekter eller roller (eller begge dele).
  • CRC-kort: CRC står for kandidater, ansvar, samarbejdspartnere. De er indekskort, der blev brugt i et tidligt design til optagelse af kandidater. Disse kort er opdelt i en uforet og en foret side.
    • Indholdet af linjesiden: På denne side registreres kandidatens navn, dets ansvar og dets samarbejdspartnere.
    • Indhold af uforet side: På denne side registreres kandidatens navn, dets formål i applikationen, stereotype roller og alt, hvad der er værd, såsom navnene på roller i mønstre, som den deltager i.
  • Hot Spots: Hot Spots er punkter i applikationen, hvor der forekommer variationer. De optages ved hjælp af Hot Spot-kort.
  • Hot Spot-kort: Hot Spot-kort bruges til at optage variationer med lige nok detaljer, så du kan skelne mellem vigtige forskelle. I lighed med CRC-kort oprettes disse også fra indekskort . Disse kort består af:
    • Hot Spot-navn
    • Generel beskrivelse af variationen
    • Mindst to specifikke eksempler, hvor variationen opstår

Objekter

Objekter beskrives som ting, der har maskinlignende adfærd, der kan sættes sammen for at arbejde sammen. Disse objekter spiller veldefinerede roller og indkapsler scriptede svar og information.

  • Objektkvarterer: Et andet udtryk for delsystem. Det er en logisk gruppering af samarbejdspartnere.
  • Ansvar: Et ansvar er en forpligtelse til at udføre en opgave eller kende information. Disse er yderligere kategoriseret efter deres brugsscenarie.
    • Offentligt ansvar: Offentligt ansvar er det ansvar, et objekt tilbyder som tjenester til andre, og de oplysninger, det giver andre.
    • Privat ansvar: Privat ansvar er de handlinger, et objekt tager til støtte for offentligt ansvar.
    • Underansvar: Nogle gange opdeles et stort eller kompliceret ansvar i mindre kaldet underansvar. De er yderligere kategoriseret ud fra hvad de gør.
      • Underordnet ansvar: Disse inkluderer de vigtigste trin i hver underansvar.
      • Sekventeringsansvar: Disse henviser til sekventeringen af ​​udførelsen af ​​underordnede ansvarsområder.

Roller

Objektrolle refererer til et udvendigt billede af, hvilken generel service der tilbydes af objektet. Det er et sæt beslægtede ansvarsområder. Det kan implementeres som en klasse eller en grænseflade. Interface er dog den foretrukne implementering, da det øger fleksibiliteten ved at skjule den betonklasse, der i sidste ende udfører arbejdet.

Rollestereotyper: Rollestereotyper er forenklede roller, der kommer med foruddefinerede ansvarsområder. Der er flere kategorier.

  • Controller: Objekt, der implementerer denne rolle, træffer beslutninger og styrer tæt andre handlingers handlinger.
  • Koordinator: Denne rolle reagerer på begivenheder ved at delegere opgaver til andre.
  • Informationsindehaver: Informationsindehaver kender og giver information.
    • Informationsudbyder: En mindre variation af en informationsindehaver er informationsudbyderen, som tager en mere aktiv rolle i styring og vedligeholdelse af information. Denne skelnen kan bruges, hvis en designer har brug for at blive mere specifik.
  • Interfacer: Denne rolle transformerer information og anmodninger mellem forskellige dele af en applikation. Det er yderligere opdelt i mere specifikke roller.
    • Ekstern grænseflade: Ekstern grænseflade kommunikerer med andre applikationer snarere end sin egen. Det bruges hovedsageligt til indkapsling af ikke-objektorienterede API'er og samarbejder ikke meget.
    • Intern interfacer: Også kaldet intersystem interfacer. Det fungerer som en bro mellem objektkvarterer.
    • Brugergrænseflade: Brugergrænseflade kommunikerer med brugerne ved at reagere på begivenheder genereret i brugergrænsefladen og derefter videregive dem til mere passende objekter.
  • Tjenesteudbyder: Denne rolle udfører arbejde og tilbyder computertjenester.
  • Strukturator: Denne rolle opretholder relationer mellem objekter og information om disse forhold.

Kontrolstil

En vigtig del i den ansvarsstyrede designproces er fordelingen af ​​kontrolansvar, der resulterer i at udvikle en kontrolstil. En kontrolstil er bekymret for kontrolflowet mellem undersystemer .

  • Begreb kontrol: Ansvaret og samarbejdet mellem klasserne.
  • Kontrolcentre: Et vigtigt aspekt ved udvikling af en kontrolstil er opfindelsen af ​​såkaldte kontrolcentre. Dette er steder, hvor objekter, der har til opgave at kontrollere og koordinere, bor.
  • Kontrolstil variationer: En kontrolstil findes i tre forskellige variationer. Disse er ikke præcise definitioner, men da en kontrolstil kan siges at være mere centraliseret eller delegeret end en anden.

Centraliseret kontrolstil

Denne kontrolstil påfører applikationsstrukturen et proceduremæssigt paradigme og placerer ansvar for større beslutningstagning kun i et par objekter eller et enkelt objekt.

Typer
  • Tilbagekaldsmodel: Styringen af ​​objekterne i applikationen foregår på hierarkisk måde. Kontrol starter ved rod og bevæger sig nedad. Det bruges i en sekventiel model.
  • Manager-model: Styringen af ​​objekterne i applikationen er kun med et objekt. Generelt implementeres det i samtidige modeller. Det kan også implementeres i sekventiel model ved hjælp af sagserklæring .
Fordele
  • Applikationslogik er ét sted.
Ulemper
  • Kontrollogik kan blive alt for kompleks
  • Controllere kan blive afhængige af indholdsholdernes indhold
  • Objekter kan kobles indirekte gennem handlinger fra deres controller
  • Det eneste interessante arbejde udføres i controlleren
Hvornår skal man bruge det?

Når beslutninger, der skal træffes, er få, enkle og relateret til en enkelt opgave.

Delegeret kontrolstil

En delegeret kontrolstil ligger imellem en centraliseret og spredt kontrolstil. Det videregiver noget af beslutningsprocessen og meget af handlingen til objekter, der omgiver et kontrolcenter. Hvert nabobjekt har en vigtig rolle at spille. Det kan også kaldes som begivenhedsdrevet model, hvor kontrollen delegeres til objektet, der anmoder om at behandle begivenheden.

Typer [reference]
  • Broadcast-model: En begivenhed udsendes til alle objekter i applikationen. Objektet, der kan håndtere begivenheden, kan erhverve kontrollen.
  • Interrupt-driven model: Der vil være interrupt handler til at behandle interrupt og videregiver til et objekt for at behandle det.
Fordele
  • Det er let at forstå.
  • Selvom der er en ekstern koordinator, kan objekter gøres smartere for at vide, hvad de skal gøre, og kan genbruges i andre applikationer.
  • Delegeringskoordinatorer har tendens til at vide om færre objekter end dominerende controllere.
  • Dialoger er på højere niveau.
  • Det er let at ændre, da ændringer typisk påvirker færre objekter.
  • Det er lettere at opdele designarbejde blandt teammedlemmer.
Ulemper
  • For meget ansvarsfordeling kan føre til svage objekter og svagt samarbejde
Hvornår skal man bruge det?

Når man ønsker at uddelegere arbejde til objekter, der er mere specialiserede.

Klynget kontrolstil

Denne kontrolstil er en variation af den centraliserede kontrolstil, hvor kontrollen indregnes blandt en gruppe objekter, hvis handlinger er koordineret. Hovedforskellen mellem en grupperet og delegeret kontrolstil er, at i en grupperet kontrolstil er beslutningsobjekterne placeret i et kontrolcenter, mens de i en delegeret kontrolstil for det meste er uden for.

Spredt kontrolstil

En spredt kontrolstil indeholder ikke nogen kontrolcentre. Logikken er spredt over hele populationen af ​​objekter, holder hvert objekt lille og bygger i så få afhængigheder blandt dem som muligt.

Fordele
  • Ingen
Ulemper
  • Når du vil finde ud af, hvordan noget fungerer, skal du spore rækkefølgen af ​​anmodninger om tjenester på tværs af mange objekter
  • Ikke særlig genanvendelig, fordi intet enkelt objekt bidrager meget
Hvornår skal man bruge det?

Aldrig.

Foretrukket kontrolstil

Efter omfattende resultater af udførte eksperimenter er det kun den øverste ledelse, der har de nødvendige færdigheder til at gøre brug af delegeret kontrolstil og centraliseret kontrolstil gavner programmører. Der er ingen sammenhæng nævnt om medarbejderne på mellemniveau.

Referencer

Bibliografi