Presentasjon lastes. Vennligst vent

Presentasjon lastes. Vennligst vent

Prinsipper og Patterns Design-beslutninger i Objekt-orientert programmering.

Liknende presentasjoner


Presentasjon om: "Prinsipper og Patterns Design-beslutninger i Objekt-orientert programmering."— Utskrift av presentasjonen:

1 Prinsipper og Patterns Design-beslutninger i Objekt-orientert programmering

2 Agenda Introduksjon til patterns Prinsipper – Abstrakte retningslinjer for design Patterns – Konkrete løsninger på design problemstillinger GOF Patterns – [GOF = ”Design Patterns: Elements of...”] – Noen av de 23 arketypiske patterns fra GOF

3 Prinsipper Løs kobling Høy sammeheng Innkapsling Polymorfi

4 Hva er ”prinsipper” Abstrakte retningslinjer for hva man bør fokusere på under design Fokuserer på prioriteringer, ikke løsninger Ikke riktige i alle situasjoner Gir gjerne begrunnelse for Patterns Hjelper å skape gode abstraksjoner

5 Sentrale prinsipper Løs kobling – samspill mellom komponenter Høy sammenheng – innhold i en komponent Innkapsling – grensesnitt til omverden Polymorfi – utbyttbar funksjonalitet

6 Løs Kobling (low coupling) Def: Liten kontaktflate mellom komponenter – Delt data (direkte aksess, globale data, metode args) – Fan-in, fan-out (metodekall) Håntere kompleksitet – Endringer har forutsigbare konsekvenser – Komponenter kan testes separat (Unit test) Hindrer at logikk sprees over mange komponenter Hver komponent kan forståes og vedlikeholdes for seg Bedre gjenbruk av komponenter

7 Høy sammenheng (high cohesion) ”A class should do one thing and do it well” Innholdet av en komponent bør være sterkt knyttet sammen Dvs. all funksjonalitet i en komponent bør høre sammen Komponenten har ett formål/ansvar Lettere å forstå, gjenbruke og teste Meningsfylt enhet  Bedre abstraksjoner

8 Innkapsling Ekspert-prinsippet Holder beslutninger samlet – Kan bytte ut komponenter – Kan endre implementasjon i komponenter – Kan introdusere ny funksjonalitet i komponenter Fører til lavere kobling mellom komponenter Fører til høyere sammenheng internt i en komponent For eksempel med Interfaces Eksempel der dette ikke er fulgt: Struct-klasser

9 Polymorfi Klienter blir koblet til én klasse/interface, istedet for mange  lavere kobling Runtime (dynamisk) vs. Compile-time (statisk) Gir muligheten til å utvide programmer etter at de er shippet Eks. COM: Definerer et interface som alle utvidelser må bruke

10 ”Don’t Repeat Yourself” DRY-prinsippet er en måte å se om kode er god på (Code smells) Hvorfor ikke: – Mer kode å skrive – Mer kode å teste – Mer kode å forstå – Mer kode  Flere feil Gjentatt kode er ofte symptom på høy kobling

11 Patterns Bakgrunn Formål Bruk

12 En Løsning på et Problem i Kontekst Løsning – Utprøvd – Bygger på ekspert-kunnskap og erfaringer – ”Generativ” – forteller hvordan man skal utføre løsningen Problem – Krefter/avveininger – Formål med/krav til en løsning Kontekst – Formål og begrensninger

13 Hvorfor Patterns? Dokumentere og eksemplifisere ekspert- kunnskaper og erfaringer Overføring av kompleks og erfaringsbasert kunnskap og innsikt Løser problemer som oppstår ”i felten” Felles vokabular for å snakke om problemer og løsninger

14 Bakgrunn Ikke nødvendigvis software Christopher Alexander ”The Timeless Way of Building” Formålet med ”The Timeless Way” var å gjøre kunnskapen til erfarene arkitekter tilgjengelig for uerfarene

15 Alexander Eksempel: Sitting Circle...A group of chairs, a sofa and a chair, a pile of cushions – these are the most obvious things in everybody's life – and yet to make them work, so people become animated and alive in them, is a very suble business. Most seating arrangements are sterile, people avoid them, nothing ever happens there. Others seem somehow to gather life around them, to concentrate and liberate energy. What is the difference between the two? …therefore Place each sitting space in a position which is protected, not cut by paths or movements, roughly circular, made so that the room itself helps suggest the circle – not too strongly – with paths and activities around it, so that people naturally gravitate toward the chairs when they get into the mood to sit. Place the chairs and cusions loosely in the circle, and have a few too many.

16 Pattern ”Language” System av sammenhørende patterns Vi vil bare se på ”Design Patterns”, men andre eksisterer For eksempel – AnalysisPatterns – AntiPatterns – OrganizationPatterns/ProcessPatterns – ProgrammingIdeoms

17 Design Patterns Omhandler samspillet mellom et lite antall objekter i programmet Fokuserer på implementasjonsmessige teknikker Løser relativt ”små” problemer, ikke arkitektur- orienterte eller domene-orienterte problemstillinger

18 Design Pattern Form  Situasjonen patternet kan brukes  Program struktur patternet leder til  Komponenter  Samspill  Resultater og avveininger  Hva bruk vil føre til  Hvilke problemer man fortsatt må løse  Eksempler  Implementasjon  Patternet i brukt

19 Bruk av design patterns Problemløsning i OO systemer – Lære – teknikker – Diskutere – alternativer – Vurdere – krefter/avveininger – Løse – problemet – Dokumentere – løsningen Kommunikasjon – felles vokabular – Diskusjon – Dokumentasjon

20 Patterns vs Prinsipper Patterns er konkrete – Problem-/løsning-orientert – Generative – beskriver strukturen til en løsning Patterns bygger på erfaringer – Ideer som er prøvd ut i praksis – ”Destillert” ekspert-kunnskap Patterns er beskrevet relativt til et problem og en sammenheng

21 Oppsummering – Virkelige patterns Virkelige problemer – Oppstår i praksis Virkelig ekspertise – Erfaringer fra bransjen Virkelige løsninger – Utprøvd og kjente

22 GOF Patterns Builder Observer Proxy Strategy State

23 Utvalgte Patterns Jeg kommer til å gi en rask oversikt over: – Strategy – Builder – Observer – Proxy (Handle/Body) – State Det er mange uklarheter ute å går, og beste måten å få svart på dem, er diskusjon

24 Å lære patterns Lesing og diskusjon Utprøving i praksis De fleste patterns har mange åpne spørsmål der diskusjoner kan være fruktbare For eksempel Singleton: – Når opprettes Singleton objektet? (Første bruk, eller oppstart?) – Hva med multithreading? Er singleton-objektet threadsafe? – Hva med utskiftbare singletons? Dynamisk lasting? – Singleton skaper større Kobling – hvordan kan dette reduseres?

25 Strategy Formål: Gjøre en algoritme utskiftbar – Kompliserte variasjoner – Fremtidig/dynamiske utvidelser Bruksområder: – Beregne avlede verdier (skatter, avgifter, avkastning) i kompliserte situasjoner – Styre layout og formattering – Sorteringsalgoritmer avhengig av array-størrelse Dersom man har kode som skjekker på flag el. og gjør nokså forskjellig ting avhengig av flaggene, kan strategy være en bedre løsning

26 Strategy - struktur

27 Builder Formål: Kode som styrer hvordan ting skal bygges skal – Kompliserte objekter – Serier med objekter som skal konstrueres likt, men representerer forskjellige ting Brukt: Bygge SQL utsagn – Gitt en liste av felter, bestemmer Concrete Builder hvilket SQL uttrykk som skal bygges opp (SELECT, DELETE, UPDATE, INSERT) Eksempel: Dialog Dersom man har duplisert kode for å lage objekter som har mange likhetstrekk, kan Builder hjelpe

28 Builder - struktur

29 Observer Formål: Manipulerer hendelsesbaserte rammeverk Brukt: Rapportering Eksempel: COM Connection Points, SAX XML Parser Callbacks og meldingshåntering i Win32 er en ikke-OO variant av det samme prinsippet

30 Observer - struktur

31 Proxy Formål: Skjule eller modifisere aksess til et objekt Implementasjon: I stedet for å kommuniserer direkte med et objekt, kommuniserer bruker-objektet gjennom en ”stedfortreder” Smart-pekere (refcount, monitor) Delayed creation – man har ikke tilstrekkelig info (eks. Verdipapir), eller objektet krever mye ressurser DCOM Proxy-stub arkitektur

32 Proxy - struktur

33 State Spørsmål: Hvordan kan man endre klassen til et objekt i løpet av objektets levetid? Implentasjon: Delegerer kall videre til ”state” objektet, og skifter ut state objected når tilstanden endrer seg Eksempler: Brukergrensesnitt; DOM tre generator som bruker SAX; E-handel Eksempel: Motor, pushGasPetal utfører MoveForward dersom state Shift ikke er revers, og MoveBackward, dersom state Shift er revers.

34 State – struktur

35 State - diskusjon Hvem er ansvarlig for minnet til State objekter? – Bør ”ConcreteState” klassene være singletons? – Bør man unngå å lage nye objekter hver gang staten endrer seg? Hva med states som skal kunne ”gå tilbake” til forrige state? Hva med states som inneholder variable? Skal state-overganger styres sentralt, eller distribuert? Distribuert state kontroll: Må man ha syklisk avhengighet mellom statene?

36 Videre informasjon Christopher Alexander: ”The Timeless Way of Building”, [GOF] Gamma, Vlissides, Helm, Johnson ”Design Patterns: Elements of Reusable OO Software Design”, Bushman, Meunier, Rohnert, Sommerlad, Stal: ”Pattern Oriented Software Architecture: A System Of Patterns”, 1996 PLoP og EuroPLoP (Pattern Languages of Program design), erences/ erences/ Bok: ”Pattern Languages of Program Design 1-4” LanguagesOfProgramDesign LanguagesOfProgramDesign DesignPatterns DesignPatterns


Laste ned ppt "Prinsipper og Patterns Design-beslutninger i Objekt-orientert programmering."

Liknende presentasjoner


Annonser fra Google