IMT 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.