IMT3102 - OOSU 28.sept

1. 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)

2. Ansvarsformer : Handling og Kunnskap Handling (Doing) : • Doingsomethingitself, such as creating an object or doingcalculation • Initiating action in otherobjects • Controlling and coordinationactivities in otherobjects Kunnskap (Knowing): • Knowingabout private encapsulated data • Knowingaboutrelatedobjects • Knowingaboutthings it canderive 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).

3. Hvaer GRASP ? • Grasp = forstå, fatte, gripe taki • Grasp: General Responsibility Assignment Software Patterns • Craig Larmanharlansertniulike GRAS-Patterns tilbruk 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.

4. forts. GRASP • GRASP: General Responsibility Assignment Software Patterns (kommenterer5 avtotalt 9) • Low Coupling • High Cohesion • Information expert • Creator • Controller • DetteersnarereOO-prisipperennreelle patterns, men de setter oss inn i tankegangenomogverdien i å ha generelleløsningsskisser.

5. GRASP # 1 : Low Coupling Problem : Hvordanholdeavhengigheterogkonsekvenseravendringer lave ogmuliggjøregjenbruk ? Løsning : Plasseransvaretslik at koblingerforblirrimelig 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

6. GRASP # 2 : High Cohesion Problem : Hvordanbeholdeoversiktogstyringikomplekseog store systemer Løsning : Plasseransvaretslik at den funksjonellestyrkenblirhøyi hverenkelt del avsystemet Kontekst: Konsekvenseneav å ha en “allviter-klasse” tiltaansvar for mange systemoperasjonergjør at dennefåransvar for en rekkeureltaterte 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

7. GRASP # 3: Information Expert Problem : Hvabørværedetgenerelleprinsippnårdetgjelder å knytteansvartilobjekter Løsning : Plasseransvaretpå den klassensomharnok informasjontil å oppfylleansvaret. (Gjennom “doing” og “knowing”) Eksempel : Ordreerinformasjonsekspert for Totalsum, Ordrelinjener informasjonsekspert for delsummene, Produktbeskrivelse vet prisen Diskusjon : I stor grad intuisjonsbasert OO Fordeler : Vedlikeholdbarhet og robusthet i løsningen Beslektede patterns / prinsipper : LowCoupling og HighCohesion Kjent som : ”Do It Myself” , ”Place responsibilitieswith data”

8. GRASP # 4 : Creator (intro til Singleton) Problem : Hvemskal ha ansvaret for å kreerenyeinstanserav en klasse Løsning : Giklassen B ansvaret for å kreereinstanseravklassen A hvis : B aggregerer / inneholder A, B arkiverer A objekter, B hyppigbruker A, B harinitialiseringsdata for A Eksempel : SalgaggregererSalgslinje, ogbør ha ansvar for at detkreeresinstanser avSalgslinje 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 : LowCoupling, Factory

9. GRASP#5: Controller (intro til Observer) Problem : Hvemskalværeansvarlig for å håndtere system hendelsesomerinitiertav en eksternaktør ? Løsning : Plasseransvaret for å håndtere “system event message” til en klassesomerspesialiertpå å delegereansvarogkoordinereaktiviteten Eksempel : En ren system-kontrollklasse Egnekontrollerklasser 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.