IMT3102 - OOSU 28.sept

Dagens tema : forts. DESIGN PATTERNS

ObjektOrientert Design =

Bevissthet i tildeling/fordeling av ansvar til

softwareklasser for å ivareta systemoperasjonene

(realisere brukernes krav). Grunnleggende prinsipper for ansvarstildeling

Modelleringsteknikker for å fremme, diskutere og

dokumentere plassering av ansvar på softwareklasser.

(RDD – Responsibility Driven Design)

Ansvarsformer : Handling og Kunnskap

Handling (Doing) : Doing something itself, such as creating an object or doing calculation Initiating action in other objects Controlling and coordination activities in other objects

Kunnskap (Knowing): Knowing about private encapsulated data Knowing about related objects Knowing about things it can derive or calculate

Craig Larman,

Det er objektene som ivaretar selve ansvaret. Ansvarsformene implementerer man i form av metoder som defineres av klassene. I vårt emne er målet å øke bevissthet rundt plassering av ansvar på klasser. Det blir mest fokus på Applikasjons- og Domenelaget og dermed i mindre grad Presentasjons- og Databaselaget (jfr. en fire-lags arkitektur).

Hva er GRASP ?

Grasp = forstå, fatte, gripe tak i

Grasp: General Responsibility Assignment Software Patterns Craig Larman har lansert ni ulike GRAS-Patterns til bruk i forbindelse med at

man gjennomfører et objektorientert design

Dette er ”patterns” som i stor grad utgjør byggestenene for de mer

detaljerte Design Patterns.

GRASP navngir og beskriver fundamentale prinsipper for tildeling av

ansvar innen OOD, fremfor å gi utvikleren en generell løsningsskisse for en

konkret problemstilling (jfr. Pattern). De betraktes derfor av mange som

byggeklosser for øvrige Design Patterns som vi skal gå gjennom senere.

forts. GRASP

GRASP: General Responsibility Assignment Software Patterns (kommenterer 5 av totalt 9)

Low Coupling High Cohesion Information expert Creator Controller

Dette er snarere OO-prisipper enn reelle patterns, men de setter oss inn i tankegangen om og verdien i å ha generelle løsningsskisser.

GRASP # 1 : Low Coupling

Problem : Hvordan holde avhengigheter og konsekvenser av endringer lave og muliggjøre gjenbruk ?

Løsning : Plasser ansvaret slik at koblinger forblir rimelig lave

Diskusjon : Har alltid vært et ideal innen software-design, ut fra at det øker vedlikeholdbarheten, lettfatteligheten og

erstatningsmulighetene og gjenbruksmulighetene til sub-systemer, moduler og komponenter

Motforestillinger :

Høy kobling til stabile elementer (som for eksempel standardbiblioteker i utviklingsverktøy) er ikke noe problem. Man må finne ikke overdrive og lage få store klasser som løser alt mulig selv, og dermed ikke er avhengig av tjenester fra andre.

Fordeler : Vedlikeholdbarhet og robusthet i løsningen

GRASP # 2 : High Cohesion

Problem : Hvordan beholde oversikt og styring i komplekse og store systemer

Løsning : Plasser ansvaret slik at den funksjonelle styrken blir høy i hver enkelt del av systemet

Kontekst : Konsekvensene av å ha en “allviter-klasse” til ta ansvar for mange

systemoperasjoner gjør at denne får ansvar for en rekke ureltaterte

oppgaver

Diskusjon : Legg et relativt lite antall metoder på klassen. Disse bør ha funksjonalitet klart relatert til det klassen er tenkt å

ivareta.

Motforestillinger :Det kan være hensiktsmessig å samle spesiell funksjonalitet / tjenester i en løsning til noen få klasser.

Fordeler : Lett å sette seg inn i løsningen og trykt å endre

GRASP # 3 : Information Expert

Problem : Hva bør være det generelle prinsipp når det gjelder å knytte ansvar til objekter

Løsning : Plasser ansvaret på den klassen som har nok

informasjon til å oppfylle ansvaret. (Gjennom “doing” og “knowing”)

Eksempel : Ordre er informasjonsekspert for Totalsum, Ordrelinjen er

informasjonsekspert for delsummene, Produktbeskrivelse vet prisen

Diskusjon : I stor grad intuisjonsbasert OO

Fordeler : Vedlikeholdbarhet og robusthet i løsningen

Beslektede patterns / prinsipper : Low Coupling og High Cohesion

Kjent som : ”Do It Myself” , ”Place responsibilities with data”

GRASP # 4 : Creator (intro til Singleton)

Problem : Hvem skal ha ansvaret for å kreere nye instanser av en klasse

Løsning : Gi klassen B ansvaret for å kreere instanser av klassen A hvis :

B aggregerer / inneholder A, B arkiverer A objekter,

B hyppig bruker A, B har initialiseringsdata for A

Eksempel : Salg aggregerer Salgslinje, og bør ha ansvar for at det kreeres instanser

av Salgslinje

Diskusjon : Legger ansvaret for å kreere instanser til et objekt som uansett skal

være tett knyttet til den aktuelle objektet.

Motforestillinger: Dette er en ”enkel” og rimelig ”lokal” løsning. Omstendighetene rundt kreering kan ofte være kompleks, og en delegering av

ansvaret for

kreering til spesialiserte klasser håndteres av ulike Design Patterns.

Fordeler : Ivaretar lave koblinger og dermed vedlikeholdbarhet og robusthet

Beslektede patterns / prinsipper : Low Coupling, Factory

GRASP#5: Controller (intro til Observer)

Problem : Hvem skal være ansvarlig for å håndtere system hendelse som er initiert av en ekstern aktør ?

Løsning : Plasser ansvaret for å håndtere “system event message” til en klasse som er spesialiert på å delegere ansvar og koordinere

aktiviteten

Eksempel : En ren system-kontrollklasse

Egne kontrollerklasser pr Use-Case

Diskusjon : Kontrolleren blir en fasade inn mot applikasjonslaget fra presentasjonslaget. Ikke la GUI-klassene sitte med

kontroll over hvordan ”forespørsler” blir håndtert og ansvaret blir fordelt. Dette overlates til en Kontroller.

Fordeler : Gir fleksibilitet med hensyn til hyppige endringer i presentasjonslaget i løsningen.