350 likes | 502 Views
Ansvarsdrevet design og bruk av design-mønstre. 04.11.2005 Kirsten Ribu. I dag. Design = klassediagram Mønstre – Patterns. Opprinnelsen til begrepet mønstre. Ideene bak design patterns stammer fra arkitektfaget, hvor Christopher Alexander utviklet et stort antall designmønstre
E N D
Ansvarsdrevet design ogbruk av design-mønstre 04.11.2005Kirsten Ribu
I dag • Design = klassediagram • Mønstre – Patterns
Opprinnelsen til begrepet mønstre • Ideene bak designpatterns stammer fra arkitektfaget, hvor Christopher Alexander utviklet et stort antall designmønstre • Professor i arkitektur ved University of California, Berkeley • Har skrevet en rekke bøker, som viser 'en ny vei' til bedre design • Tar et oppgjør med det tradisjonelle designparadigmet, som er basert på en faseoppdelt framgangsmåte: • Analyse leder til spesifikasjon, som er grunnlag for konstruksjon (fossefall)
Klasser og objekter I UML er klasser og objekter illustrert på samme grafiske måte, men navnet er understreket i objektene. Spørsmål :Spørsmål s1:Spørsmål klasse objekt navngitt objekt
Objektdesign:Ansvarstilordning • UML definerer ansvar som en ’kontrakt’ i en klasse • Ansvar er knyttet til objektet i form av dets oppførsel • Handling: Opprette objekt, beregning • Kunnskap: Vite om private data, vite om relaterte objekter • Ansvar er ikke det samme som metoder, men metoder implementeres for å oppfylle ansvaret • Ansvarstilordning: En utfordring under utforming av sekvens-diagrammer
Objektdesign • Ekspertprinsippet: La det objektet som har kunnskapen (dataene) også behandle den (Eksempel ’Spørreskjema’) • Kontrollobjektprinsippet: Velg objekt som håndterer systemhendelser (Eksempel: ’SpørreskjemaHåndterer’ – use case kontrollobjekt) • Skaperprinsippet: Legg ansvar for å opprette et nytt objekt i klassen som må vite om det nye objektet (Eksempel: ’SpørreskjemaGenerator’)
Kontrollobjekter • Hver use case kan ha et kontrollobjekt som styrer flyten i use caset • Kontrollobjektet er et grensesnitt-objekt • Kontrollobjekter delegereroppgaver til andre objekter
Hvorfor bruke mønstre (patterns) for informasjonssystemer? • Mye av vårt daglige virke består i å lete etter strukturer (mønstre) i omgivelsene • Mønstre er vanlige løsninger på vanlige problemer • Det samme gjelder utvikling av informasjonssystemer • Mange systemer har grunnleggendefellestrekk • Det finnes mange mønstre (patterns) som er blitt utviklet gjennom systemutviklingens historie
Produksjon og konsumpsjon Påstand: • Mennesker er: • Produsenter av varer og tjenester • Konsumenter av varer og tjenester • Mange av våre aktiviteter er former for ’kjøp/salg’ og produksjon • Informasjonssytemer gjenspeiler og styrer våre aktiviteter • Vi kan derfor (grovt) betrakteinformasjonssystemersom varianter av kjøp/salg/produksjons-systemer
Fellestrekk ved informasjonssystemer • Kan et kjøp/salg/produksjon system kan danne et grunnlag – mønster – for andre informasjonssystemer ? • I et hvilket som helst system, hva er det som tilsvarer • Ordrene • Varene • Regnskap • Leverandøren • Kunden etc.
Gjenkjennelige trekk • Vi finner igjen salgssituasjonen i mange sammenhenger • Det er ofte nok til å komme i gang med en use case modell • Og deretter et klassediagram. • Vanlige klasser i et slikt system kan f.eks være: • Ordre • Lager • Leverandør • Kunde • Produkt • Faktura
Problem/løsning - par • Kritiske designspørsmål: • Hvordan allokere ansvar til klasser? • Hvordan skal objekter samarbeide? • Hvilke klasser skal gjørehva? • Noen utprøvde løsninger på designproblemer =best-practice prinsipper (mønstre) = patterns: eksemplifiserte kodeløsninger på design-prinsipper
Gjenbruk av løsninger • Hensikt: å omsette eksisterende design kunnskap til et kodeskjelett • Man trenger ikke finne opp hjulet på nytt hver gang …. • Å navngimønstrene letter kommunikasjonen mellom utviklerne
Retningslinjer for god objektdesign • ’Design patterns’ er navngitte retningslinjer for hvordan ansvar skal fordeles i ulike situasjoner • GRASP – ’Patterns of General Principles in Assigning Responsibilites’: Mønster for problem/løsning
GRASP? • InformationExpert (Eksperprinsippet) • Creator (skaperprinsippet) • Controller (kontrollprinsippet) • Høykohesjon • Lavkobling
Objektdesign • Ekspertprinsippet: La det objektet som har kunnskapen (dataene) også behandle den • Kontrollobjektprinsippet: • To typer kontrollere: • Fasadekontroller: En kontrollklasse har ansvar for alt (brukes i et lite system) • Use case kontroller: Styrer ett use case (brukes i større systemer. Et kontrollobjekt for hvert use case). • Skaperprinsippet: Legg ansvar for å opprette et nytt objekt i klassen som må vite om det nye objektet
Information Expert • Tildel ansvar til den klassen som har tilgang til den nødvendige informasjonen for å gjøre jobben • Eksempel: I et salgssystem: Metoden ’hentKundenummer()’ legges i klassen som har variabelen ’kundenr.’ • Fordel: • Oppnår på denne måten lav kobling og høy kohesjon • Ulemper: • Kan få for store klasser ved at for mye ansvar puttes inn i en klasse. • Løsning: Fordel ansvaret på to klasser
Creator • Problem: Hvilken klasse er ansvarlig for å opprette nye objekter? • Løsning: La det objektet som må vite om de nye objektene lage dem • Hvordan: Gi klasse B ansvaret for å opprette et objekt av klasse A dersom ett av følgende er sant: • B inneholder A-objekter • B bruker A-objekter • B har data som sendes til A-objektet når det opprettes Eksempel: • KlasseB objektA = new KLasseB() • Ulempe: Klasse A og B har høy kobling
Controller • Hvilken klasse skal behandle en systemhendelse/melding? • Kontrolleren ligger gjerne på klienten • Kontrolleren har bare metoder, få eller ingen variabler. • Kontrolleren gjør ikke jobbenselv, men mottar og fordeler oppgaver – er en slags administrator • Delegereroppgaver og styrer use case. • Er et bindeledd mellom brukergrensesnittet og applikasjonslaget
’Generer spørreskjema’ igjen visSpørreskjema()
Controller eksempel GUI • Fordel: Lett å bytte ut klassene over og under kontrollklassen, spesielt gernesesnitt • Styrer hendelsesforløpet i et use case Controller Kunde kundedatabase fasade
Controller forts. • Ulemper: • Mange metodekall sinker systemet • Mye koding • Flere klasser • Kontrollere får for mye ansvar = mangel på kohesjon: • Kontrolleren har for mange jobber å gjøre. • Ansvaret og attributtene skulle vært distribuert
Ekspertprinsippet (Information Expert) • Problem: Hva er det generelle prinsipp for å tilordne ansvar til objekter? • Løsning: La det objektet som har kunnskapen (dataene) også behandle den • Hvordan: • Begynn med å formulere ansvarsområdet: Hvilket objekt har ansvar for å viteom det totale antall svar på undersøkelsen?
Skaperprinsippet (Creator) • Problem: Hvem er ansvarlig for å opprette nye objekter? • Løsning: La det objektet som må vite om de nye objektene lage dem • Hvordan: Gi klasse B ansvaret for å opprette et objekt av klasse A dersom ett av følgende er sant: • B inneholder A-objekter • B bruker A-objekter • B har data som sendes til A-objektet når det opprettes
Finn systemklasse • Vi trenger en ’SpørreskjemaGenerator’ klasse for å opprette nye skjemaer
Mer om Patterns • GOF etc….
Gang of Four (GoF) Erich GammaRichard HelmRalph JohnsonJohn Vlissides – forfatterne av boka ’Design Patterns, Elements of Reusable Object-oriented Software’ ble kjent som Gang of Four. Navnet var for langt til å brukes i e-mail, derfor ’firerbanden’. Deres mønstre er kjent som GoF patterns.
GOF (Gang of Four) 23 Mønstre • Creational Patterns (5) • Abstract Factory, Builder, Factory Method, Prototype, Singleton • Structural Patterns (7) • Adapter, Bridge, Composite, Decorator, Façade, Flyweight, Proxy • Behavioural Patterns (11) • Chain of responsibility, Command, Interpreter, Iterator, Mediator, • Memento, Observer, State, Strategy, Template method, Visitor Bok: Design Patterns av Erich Gamma (Author), Richard Helm (Author), Ralph Johnson (Author), John Vlissides (Author), Publisher: Addison-Wesley Pub Co; 1st edition (January 15, 1995) ISBN: 0201633612
GoF Patterns http://www.tml.hut.fi/~pnr/GoF-models/html/ • Behavioral – Oppførsel • Creational – Skaper • Structural - Struktur