Prinsipper og Patterns Design-beslutninger i Objekt-orientert programmering

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

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

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

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

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

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

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

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

”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

Patterns Bakgrunn Formål Bruk

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

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

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

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.

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

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

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

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

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

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

Builder Observer Proxy Strategy State GOF Patterns Builder Observer Proxy Strategy State

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

Å 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?

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

Strategy - struktur

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

Builder - struktur

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

Observer - struktur

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

Proxy - struktur

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.

State – struktur

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?

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), http://hillside.net/patterns/conferences/ Bok: ”Pattern Languages of Program Design 1-4” 95-99. http://c2.com/cgi/wiki?PatternLanguagesOfProgramDesign http://c2.com/cgi/wiki? DesignPatterns http://hillside.net/patterns/