Et design pattern er et mønster som er set i mindst tre programmer. Det er ikke noget kode. Det er ikke noget i et bibliotek. Det er selve det mønster løsningen på
problemet udgør. Faktisk er det et af de store problemer med patterns. Det er så svært at pege på præcis hvad et pattern er. Nogle fastholder at et pattern er beskrivelsen, og ingen tvivl
om det; beskrivelsen og navnet er vigtige elementer i et design pattern.
Grundene for at lære patterns er mange:
- Hvert pattern repræsenterer - ofte dyrekøbte -erfaringer. Design Patterns er et forsøg på at overføre denne erfaring.
- Et patterns navn bliver en udviddelse af hvad det er nemt at sige, når man taler med kollegaer om design.
- At have et pattern tydeliggør, hvad det er man prøver at opnå. Nogle patterns ligner meget hinanden, når man ser et klassediagram, men har forskelligt fokus.
Et eksempel på et pattern er Singleton. Singleton adresserer følgende problem: Hvordan tillader vi en bruger af vores software-bibliotek at referere til en unik global instans af en
klasse, som måske i virkeligheden er en instans af en afledt klasse? Det kunne være en klasse der kunne generere nummerplader til nye biler i vores motorvejssimulation. Løsningen singleton
foreskriver er: Lav en statisk (global) funktion, der returnerer en reference til den unikke instans. Så småt kan et pattern være, men allerede nu kan det begynde at virke. Bare fra
denne introduktion har ordet singleton fået en betydning, som vi kan bruge til at tale om et element i et design. Og singleton er hyppigt brugt. Nogle patterns er meget
sproguafhængige, andre læner sig meget op af bestemte sprogfaciliteter. Det er almindeligt at reservere ordet pattern til dem, der ikke er totalt afhængige af et enkelt sprog, og så kalde de
sprogspecifikke mønstre for ideomer i stedet. |
Den originale bog (note 1) om design patterns indeholder en række patterns, der har vist deres værd indenfor objektorienteret
programmering. De beskæftiger sig med problemer om, hvordan man får frembragt objekter, får dem til at spille sammen, og med en meget høj grad af fokus på at løsningerne understøtter løs
kobling mellem elementerne, så disse nemt kan anvendes i andre sammenhænge. Dette er et element af patterns, der hjælper med at lave genanvendelig software.
Hvornår patterns?
Hvis patterns er så godt, burde vi så ikke starte med at lære patterns? Man kan forestille sig to yderpunkter. En mand, der gennem mange år har haft elektronik som hobby og bygget
sine egne forstærkere, kan sagtens have opbygget en stor viden om hvad det er for nogle love og regler, der regerer i den verden. Hvis han en dag beslutter at frekventere en ingeniør
uddannelse, vil han uden tvivl opleve, at han kender mange af de begreber, han bliver udsat for. Men den store oplevelse vil nok komme fra at tingene i højere grad får navne og bliver sat ind
i en mere systematisk sammenhæng. En ny student, der følger de samme kurser, vil til gengæld snarere opleve stoffet som en støtte for hans almene opbygning af erfaring. Det bliver de
eksempler, han bruger, når han opbygger sin erfaring. Men han er måske nok mere tilbøjelig til at overse nogle pointer, fordi han ikke han prøvet at gøre nogle af de fejl, de adresserer. Ligeså
med patterns: For den erfarne er der tit nogle seriøse aha-oplevelser at hente. For den uerfarne er de en samling gode vaner, som man kan studere, men de kan ikke erstatte erfaring. Men måske
kan de hjælpe med at bane vejen.
1. Erich Gamma, Richard Helm, Ralph Johnson og John Vissides.
Design Patterns. Addison Wesley, 1. Edition, 1995. |
