Nytten av design patterns

Nytten av design patterns

En studie av bruken av design patterns ga nyttige og interessante erfaringer for utviklere.
Da Gamma, Helm, Johnson og Vlissides i 1994 utga boken "Design Patterns, Elements of Reusable Object-Oriented Software" ble den en umiddelbar suksess. Den første konferansen i serien Pattern Languages of Programming (PLoP) ble holdt samme år, og til sammen la de grunnlaget for en hel bevegelse.

I dag har de fleste utviklere i det minste hørt om "design patterns", selv om det fortsatt er mange som ikke kjenner spesielt godt til begrepene.

Design Pattern

Et "design pattern" i programvarsammenheng er en abstrakt beskrivelse av minimum tre ting: Et problem, en sammenheng problemet opptrer i, og en skisse til løsning. Et pattern er avledet av erfaring - her taler erfarne utviklere om løsninger som er velprøvd og som har vist seg å fungere bra. Det skisserer gjerne en struktur, en måte å sette opp arv, metodekall og andre sammenhenger mellom klasser på. Den enkelte utvikler må selv gjenkjenne at hun har et problem som et pattern beskriver løsningen til, og må selv realisere løsningen i sitt eget design.

Fra mange forsøk på å få til gjenbruk av programvare vet vi at det ofte er detaljene i både problem og sammenheng som avgjør, og som gjør direkte gjenbruk vanskelig eller umulig. Ved å bevege seg på et abstrakt nivå, slipper Design Patterns unna detaljene og får større anvendelighet - mot å kreve mer tankevirksomhet fra utviklerne.

Gode patterns-samlinger har mer omfattende beskrivelser enn bare problem/sammenheng/løsning. I noen tilfeller kan man snakke om et slags språk, Pattern Language, der flere forskjellige patterns kombineres i en sekvens, nærmest som ord i en setning.

Boken "Process Patterns" av Scott W. Ambler er et utmerket eksempel på dette, og viser samtidig hvordan man kan beskrive utviklingsprosessen, altså det menneskelige og organisatoriske, med patterns.

Kur for alt?

De fleste som skriver om "design patterns" er tilhengere og har gode erfaringer de vil dele. Det ligger i menneskers natur at det er litt vanskeligere å gå ut med negative resultater: "Vi fulgte alle metodene og fikk det ikke til" er en artikkel de færreste ønsker å skrive. På Simula-senteret har vi derfor gjort en del forskning på "design patterns", for å få på plass noen mer objektive resultater.

Det første leddet var et eksperiment, der 44 profesjonelle utviklere fra store og små konsulentselskaper utførte vedlikeholdsoppgaver på flere forskjellige programmer. Et nøye sammensatt sett av programmer, versjoner og pattern-kurs ga oss grunnlag for å gjøre en solid analyse.

Resultatene var interessante: Patternet "Observer", som brukes mye i hendelsesdrevne systemer som for eksempel Windows, viste seg å være lettfattelig og ga positive resultater. Det gikk raskere å vedlikeholde programmer som var bygget opp rundt det, og det var høy kvalitet på løsningene. Det ble til og med "gjenoppfunnet" av en av deltagerne som arbeidet på den pattern-frie utgaven av programmet, selv om han hevdet å ikke kjenne til det fra før.

Formatering

I den andre enden av skalaen var Visitor, et elegant men komplisert pattern for situasjoner der to dimensjoner av variabilitet møtes. Et eksempel kan være formatering av matematiske formler, der man kan ha flere forskjellige stilarter. En funksjon for å skrive ut en operator vil da avhenge av både hvilken operator det er, og hvilken stil som skal følges. Her var det svært få av deltagerne som hadde glede av Visitor, til tross for at det som skulle gjøres, tilsvarte et eksempel som allerede fantes i koden.

Et gjennomgående trekk var at patterns basert på rekursjon så ut til å være vanskelige å bruke, og vår teori er at det skyldes at rekursjon i liten grad brukes i det daglige. Ettersom alle programmeringsspråk nå har forskjellige slags Collection eller Container-klasser, trenger man ikke lenger å programmere trestrukturer selv - og dermed forsvinner rekursjon ut av vokabularet.

I en annen undersøkelse så vi på mulige sammenhenger mellom feilhyppighet og bruk av patterns i et større, norsk CRM-produkt. Vi sammenholdt informasjon fra versjonskontrollsystemet og et egenutviklet verktøy for å identifisere patterns i C++ kode.

Resultatene var igjen interessante: Observer var korrelert med en overhyppighet av feil, mens Factory var forbundet med færre feil. Template Method, et pattern for å dele opp en algoritme i et fast, høyt nivå, men med utskiftbare metoder på detaljnivå, hadde resultater i begge retninger.

Bra verktøy

Vår tolkning er imidlertid ikke at bruk av patterns nødvendigvis er årsaken til problemene: Det kan like mye være et symptom på at man har kommet til den komplekse kjernen av problemet som programmet skal løse.

Med andre ord: Dersom Observer er den riktige løsningen på problemet ditt, så bør du antagelig bruke litt ekstra innsats på designet, fordi du har et komplisert problem. Med Template Method kan det være både og, mens problemer som løses med bruk av Factory, later til å være mer oversiktlige.

En generell konklusjon er at patterns ser ut til å være et utmerket verktøy for formidling av design-kunnskap. Men, har man et komplisert problem og en tilsvarende komplisert løsning, vil Patterns alene ikke erstatte godt håndverk og erfaring. Til syvende og sist står utvikleren fortsatt ansvarlig for valg og anvendelse av sine metoder, uansett hva de heter.

Det neste naturlige trinnet i våre undersøkelser vil være å se på Open Source- programvare, der til dels store produkter er tilgjengelige og med mye historikk. Dersom tendensene holder seg, vil det være nyttig kunnskap for de som utvikler til daglig.

Marek Vokac;
skriver på en doktorgrad om emnet "design patterns" og skal disputere om kort tid.