Ved udgangen af 1994 startede fire forfattere en bølge, der skulle vise sig at revolutionere den objektorienterede design-verden - de skrev bogen "Design Patterns - Elements of Reusable Object-Oriented Software". Forfatterne var Erich Gamma, Richard Helm, Ralph Johnson og John Vlissides (forordet var forøvrigt skrevet af Grady Booch, der som en af de tre amigos heller ikke er blevet mindre kendt med tiden). Forfatterne fik senere øgenavnet "Gang of Four" (GoF) - "Firebanden". Bogen er blevet pligtlæsning for enhver, der vil studere design patterns, men belastes efterhånden af, at den er fra før en anden bølge startede: Java-bølgen - Alle eksempler er i C++, med enkelte i Smalltalk.
Da jeg i 1995 læste bogen, og samme år begyndte at undervise efter den, var det fordi jeg var blevet grebet af den følelse af klarsyn som bogen gav sine læsere. Før jeg læste bogen mente jeg at have godt fat i objektorienteret design. Efter at have læst den var jeg klar over min fejlvurdering, nu var mit indtryk, at jeg ikke kunne ret meget før, men nu forstod jeg det hele!
Efter at have brugt bogen i fem semestre har jeg fundet det nødvendigt at supplere den med anden litteratur, men den vil i mange år forblive højt på top-10 listen over væsentligste objektorienterede bøger.
Små PhD-studerende Siden bogen kom frem er der sket det sædvanlige. Enhver lille PhD-studerende føler sig forpligtiget til at finde sit eget pattern, som han kan sætte sit navn på, og der er til en vis grad gået inflation i den desperate søgen efter flere patterns.
Ved vurdering af patterns holder jeg mig til "min første kærlighed", idet jeg hårdnakket fastholder det meget subjektive kriterie, at et patterns værdi er ligefrem proportionalt med hvor meget jeg føler jeg har lært af at læse det.
Hvad er det jeg taler om? Hvad er et pattern?

Christopher Alexander

Arkitekt Når man skal finde ophavsmanden til design patterns, skal man pudsigt nok ikke søge blandt dataloger. Da Christopher Alexander i 1977 skrev bogen "A Pattern Language" og senere i 1979 "The Timeless Way of Building", skabte han grundlaget for den pattern-bølge vi har oplevet fra midten af 90'erne og ind i det første årti af det 21. århundrede. Alexander er arkitekt, og selv om han er professor, er han hverken berømt eller specielt anderkendt blandt andre arkitekter. Det sidste er måske ikke så væsentligt, for den succes patterns ikke har opnået i arkitekturens verden, har de til gengæld oplevet i den objektorienterede verden.

Sitting Circle

For at få et førstehånds indtryk af hvad et pattern er, kan vi passende studere et af Alexanders patterns: Sitting Circle. Sitting Circle betyder, at man sidder i en rundkreds, og med sit pattern ønskede Alexander at beskrive dette fænomens generelle karakteristika [AIS77, s. 857-60].
Hyggekrog fra de gode gamle dage

Det problem vi skal løse i forbindelse med Sitting Circle er, at stedet skal gøres egnet til formålet og det skal placeres rigtigt.
Man placerer stole, sofaer og lignende i en kreds, så man sidder med en vinkel i forhold til de nærmeste. Det er ikke rart at sidde direkte overfor andre på kort afstand. Kredsen skaber et rum mellem deltagerne og det er i dette rum man kommunikerer. For at støtte indtrykket af en kreds er det godt hvis vægge, vinduer osv. i grove træk udgør en cirkel. På fotografiet ovenfor kan man se hvorledes hjørnesofaen skaber en fast del af kredsen, og de løse stole fuldender formen, og skaber et rum omkring bordet.
Selve kredsen placeres nær trafik, dvs. folk kommer naturligt fordi og vil være tilbøjelige til at deltage i kredsen eller forlade den igen. Trafikken må ikke gå igennem kredsen, da den derved bryder det rum som er skabt. Hvis vi igen ser på fotografiet ovenfor, ser man at trafikken går gennem kredsen. Stolen til venstre er i fare for at blive isoleret af folk der går til og fra verandaen.
Ikke konkret problem-løsning Det vi her har gennemgået er et pattern. Vi har en generel beskrivelse af et problem: Hvordan vi får etableret en velfungerende rundkreds. Dernæst har vi en række principper og idéer til hvordan problemet løses. Det afgørende er, at det hele er generelt. Et pattern er ikke en løsning på et konkret problem - det er er en vejledning til hvordan man konstruerer en løsning på et problem af en bestemt slags.

Hvad er design Patterns?

Lad os vende tilbage til den objektorienterede verden. Når vi her skal søge definitionen på et pattern, finder vi den naturligvis i [GoF94, s. 3]:

Definition: Design Pattern

Et Design Pattern er en beskrivelse af kommunikerende objekter, og klasser der er lavet til at løse et generelt design-problem (i en bestemt sammenhæng).

Det sidste af definitionen (i parantes) er med fordi det står i [GoF94], men i årenes løb er det trådt i baggrunden. Der er dog stadig dem, der er meget tro mod bogens oprindelige opfattelse, som stadig vil have det med.
Grunden til, at jeg normalt nedtoner "i en bestemt sammenhæng", er fordi det svækker det generelle i et pattern; hvilket netop er kernen i hele begrebet.
Eksempler Når man introduceres til et nyt pattern er det dog altid rart med et eksempel. Stillet over for en konkret anvendelse har man lettere ved at se problemstillingen og værdien af den løsning som præsenteres. At der er denne praktiske indgang til patterns er ikke kun et pædagogisk redskab, det ligger i selve pattern-begrebet. Patterns er ikke resultatet af skrivebordsarbejde!
Deja vú Alle patterns udspringer af de problemer designere har stået overfor og de erfaringer de har haft med forskellige løsninger. Et pattern kommer til verden som et deja vú: "Jeg har tidligere løst et problem med nogenlunde de samme karakteristika som det her - Hvad var det nu lige for en idé jeg fik dengang?". Når man har oplevet dette tilstrækkelig mange gange, skriver man det ned:
Generelt

- Hvad karakteriserer problemet?
- Hvad er idéen i løsningen?

og et pattern har set dagens lys.
Bemærk at vi ikke skriver:
Konkret

- Hvad er problemet?
- Hvad er løsningen?

Det sidste er ikke et pattern. Det generelle er væk og værdien er nu begrænset til et bestemt problem. Når man har tilstrækkelig erfaring får man det overblik, der skal til for at abstrahere fra den konkrete til den generelle problemløsning, og dermed lave et rigtigt design pattern.
Balancering Med en generel problemløsning favner man bredere og løsningen får større værdi. En problemløsning kan dog blive så abstrakt at den bliver vanskelig at anvende - det bliver for vanskeligt at se, hvad man konkret skal gøre - og hvor generelt et pattern skal formuleres er derfor en balance mellem det generelle og konkrete.
Delegation Pattern F.eks. findes der et pattern, der hedder Delegation Pattern, som beskriver delegering i al sin enkelthed. Det er et pattern af ringe værdi. Ikke fordi delegering er uvæsentligt - tværtimod! - men fordi det er så abstrakt. Hvis jeg gennemgår Delegation Pattern for mine studerende, vil de ikke vide hvad de skulle bruge det til. Når de kommer i situationer hvor det kan løse problemer for dem, vil de ikke erkende det. Først når de har set en række anvendelser af delegering, bliver de i stand til at se, og værdsætte, værdien af delegering. Delegation Pattern er et indforstået pattern: Man skal have erfaring med delegering for at kunne forstå det, men har man det, er det overflødigt som pattern, for så har man netop den erfaring som ligger i Delegation Pattern.
Erfarings-dokumentation Man kan se begrebet design patterns fra flere sider når man skal beskrive det, og jeg vil slutte af med følgende vinkel: Et design pattern er en erfaringsdokumentation. Det er et redskab hvormed en erfaren designer formidler sin erfaring til en mindre erfaren designer. Ved at bruge patterns kan man kraftigt accelerere indlæringsprocessen ved at fokusere på løsningsidéer snarere end på specifikke løsninger, som først senere giver det overblik, der er målet.

Mønstre På dansk kalder man også design patterns for design mønstre. Med min sædvanlige præference for internationale fagudtryk holder jeg mig til betegnelsen patterns - måske også fordi al væsentlig litteratur om patterns er på engelsk.

Hvor begynder man?

Hvor skal man starte, når man vil studere design patterns? Det kommer an på, hvad man vil med sit studie.
Fagområde Hvis interessen/behovet udspringer af et specifikt fagområde, f.eks. netværks-programmering, kan man finde de patterns, der findes inden for dette område. Der vil normalt være tale om relativ få patterns og man kan starte sit studie med at få et overblik over de forskellige problemstillinger som disse patterns beskæftiger sig med.
Objekt-orienteret sundt Hvis det generelt er det objektorienterede, der er ens udgangspunkt, er det straks mere uoverskueligt. Det er min erfaring (både med mig selv og mine studerende), at et studie af design patterns giver en betydelig bedre objektorienteret forståelse i det hele taget. Derfor er det ikke hovedløst at studere patterns blot for deres egen skyld (i første omgang), fordi det ganske enkelt er (objektorienteret) sundt!

Hvilke patterns er de vigtigste? Det er naturligvis ikke så enkelt at svare på, men jeg vil prøve alligevel, da jeg selv synes at nogle er vigtigere end andre.
Delegering på 1000 måder Jeg har nogen gange sagt, at Patterns er "Delegering på 1000 måder". Og det er da også rigtigt, at Patterns-bølgen samtidig var starten på "komposition som et alternativ til nedarvning": Vil man have noget nyt ud fra noget gammelt, nedarver man ikke fra det - man sætter det sammen på en ny måde eller giver et gammelt objekt et nyt objekt at samarbejde med.
Ud fra denne betragtning skulle Delegation Pattern være det vigtigste, men selvom delegering er uhyre vigtigt, er det som pattern af mindre værdi - man får ikke en god forståelse af delegering ved blot at læse Delegation Pattern, man skal prøve det i mange sammenhænge før forståelsen opnås.
Proxy Pattern Proxy Pattern ligger strukturelt tæt op af Delegation Pattern, men da det har en egen idé som ikke kun ligger i et objektorienteret grundbegreb, får den en reel værdi som Pattern. Proxy Pattern er det vigtigste pattern fordi det siger, hvad vi vil med delegering - Vi vil skjule information: Information Hiding. At Proxy Pattern er det vigtigste Pattern står naturligvis kun for min regning, men det er den opfattelse jeg har fået gennem årene, selvom jeg må indrømme at dens største værdi hentes fra delegering, og dermed måske i virkeligheden fra Delegation Pattern.
Hvilke andre patterns er vigtige? Ud over Proxy Pattern måler jeg ofte vigtighed i, om et pattern anvendes i andre patterns. I den sammenhæng er Observer Pattern en stærk kandidat til førerfeltet. Det første pattern man kommer i tanke om er Model-View-Controller Pattern, som ville falde fra hinanden hvis det ikke var for Observer Pattern. Oberserver Pattern kan også anvendes i andre patterns, men hvad mere vigtigt er, er at det er så hyppigt anvendt. I mine egne projekter er det i "Top-2", sammen med Singleton Pattern.
Idiom Singleton Pattern er det man kalder et idiom: Et sprogafhængigt pattern. Det sprogafhængige ligger i, at det ikke umiddelbart giver mening i andre sprog, fordi det udnytter specielle faciliteter i f.eks. Java eller Smalltalk.

Hvad gør man?

Hellere én i hånden, end ti på taget Hvad er bedst: At kende ti patterns overfladisk eller at kunne tre dybtgående? Hvis det er den objektorienterede forståelse man går efter, er det klart bedre at få et dybtgående kendskab til nogle få patterns. Ved et dybtgående kendskab kommer man ned til roden af den objektorienterede tankegang der ligger bag, og man lærer på den måde at tænke i de samme baner. Et overfladisk kendskab til patterns giver let det indtryk at deres værdi er beskeden - at patterns er varm luft! Det væsentlige i patterns er de idéer de repræsenterer ikke deres "udseende".
I min egen undervisning plejer jeg at anvende en kombination af begge. De første X patterns gennemgåes relativ grundigt, mens de senere Y patterns bliver taget lidt mere overfladisk. Grænsen mellem X og Y er lidt udflydende, men det er vigtigt at de første bliver studeret i detaljer, da de vil stå som prototyper på Patterns i de studerendes bevidsthed. Det er altid de første man husker bedst og de er bestemmende for den holdning man udvikler til Patterns.

Prøv det! Det er altid en god idé at implementere de forskellige patterns. Derfor stiller jeg (næsten) altid en opgave til mine studerende for hvert pattern jeg gennemgår. De er ikke altid lige gode, men man får et andet forhold til et pattern når man har prøvet det, uanset at opgaven evt. har været lidt kunstig. Når man senere har fået et solidt kendskab til objektorienteret design kan man begynde at læse patterns på samme måde som nogen er i stand til at "høre" musikken når de læser noder - men det varer flere år!