Prinsipper og Patterns

Presentasjon om: "Prinsipper og Patterns"— Utskrift av presentasjonen:

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

2 Agenda Introduksjon til patterns Prinsipper Patterns GOF Patterns
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 Løs kobling Høy sammeheng Innkapsling Polymorfi
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
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 Konklusjon

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 Oppsummering

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

22 Builder Observer Proxy Strategy State
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 Bruksområder:
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”, 1979. [GOF] Gamma, Vlissides, Helm, Johnson ”Design Patterns: Elements of Reusable OO Software Design”, 1995. Bushman, Meunier, Rohnert, Sommerlad, Stal: ”Pattern Oriented Software Architecture: A System Of Patterns”, 1996 PLoP og EuroPLoP (Pattern Languages of Program design), Bok: ”Pattern Languages of Program Design 1-4” DesignPatterns