Designmønstre Baggrund og eksempler

Transkript

1 Designmønstre Baggrund og eksempler Michael E. Caspersen Datalogisk Institut Aarhus Universitet

2 Emner Introduktion til mønstre Observer en starter Om mønstre Abstraktioner og sprogmekanismer GoF Pattern Language(s) Observer, igen Programmeringsteknologi, F11 Designmønstre 2. Baggrund og eksempler.2

3 Introduktion til mønstre Mønstre i ingeniørfag, i arkitektfag og i software

4 Hvad er en ventil? En vandhane er egentlig en ventil af den type, som benævnes en sædeventil. Figuren viser hvilke foranstaltninger man tager for at gøre den tæt. (a) er det i ventilhuset fastsiddende sæde, (b) en flad eller konisk pakning. (c) og (d) pakninger mellem spindel og ventilhus (A) Skitsen viser en sædeventil med åbning for væskepassage (1) og ventilkegle (2), der undertiden er plan som her vist. (B) er en dobbelt sædeventil, hvor en vis kompensation i sædebevægelsen kan opnås. (C) viser en butterfly-ventil med et drejeligt spjæld, der ved åben ventil står parallel med strømningsretningen. På (D) ses en kugleventil en kuglehane med kugleformet told hvorigennem væsken strømmer. Programmeringsteknologi, F11 Designmønstre 2. Baggrund og eksempler.4

5 Eller en pumpe? 1. Sugepumpe med stempel (a). Ventilerne b og c åbner og lukker sig, efter som stemplet føres op eller ned. Når stemplet hæves, fortyndes luften under det, og vandet suges op i sugerøret. 2. Sugepumpe med dykkerstempel (a) og vindkedel (b). Vindkedelen forhindrer, at vandstrålen strømmer ud stødvis; luften i vindkedelen bliver sammenpresset og trykker bagefter vandet ud som en jævn strøm. 3. Tandhjulspumper anvendes mest som oliepumper. 4. Centrifugalpumpen er en strømningsmaskine, hvori et motordrevet, roterende skovlhjul (a) tilfører bevægelsesenergi til væsken, der tilledes aksialt og slynges udefter af centrifugalkraften. I et spiralformet pumpehus (b) omsættes bevægelsesenergien til tryk. Programmeringsteknologi, F11 Designmønstre 2. Baggrund og eksempler.5

6 Fra arkitekturmønstre... Christopher Alexander Notes on the Synthesis of Form (1964) The Oregon Experiment (1975) A Pattern Language: Towns, Buildings, Constructions (1977) 253 mønstre for regioner, storbyer, byer, nabolag, transport, hjem, kontorer, arbejdspladser, afslapningsområder, rum, belysning, vinduer, haver, vente-værelser, terrasser, vægge, murer, byggematerialer og konstruktion. The Timeless Way of Building (1979) Programmeringsteknologi, F11 Designmønstre 2. Baggrund og eksempler.6

7 Fra arkitekturmønstre til softwaremønstre OOPSLA Ward Cunningham & Kent Beck: Using Pattern Languages for Object-Oriented Programs (1987) Bruce Andersen, GoF, Jim Coplien, Doug Lea, Desmond D Souza, Norm Kerth, Wolfgang Pree (Workshops, ) The Hillside Group (Colorado, August 1993, April 1994) Kent Beck and Grady Booch,..., PLoP GoF: Design Patterns (1994) Resten er historie... Programmeringsteknologi, F11 Designmønstre 2. Baggrund og eksempler.7

8 Christopher Alexander om mønstre Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice. Christopher Alexander tænkte på byplanlægning og bygninger, men definitionen er også gyldig for objektorienterede designmønstre. I software er løsninger udtrykt i termer af objekter og interfaces i stedet for vægge, vinduer og døre, men kernen i et mønster er altid: A solution to a problem in a context Programmeringsteknologi, F11 Designmønstre 2. Baggrund og eksempler.8

9 Alcoves : et af Alexanders mønstre 179. Alcoves **... many large rooms are not complete unless they have smaller rooms and alcoves opening off them. No homogeneous room, or homogeneous height, can serve a group of people well. To give a group a chance to be together, as a group, a room must also give them the chance to be alone, in one s and two s in the same space. This problem is felt most acutely in the common rooms of a house the kitchen, the family room, the living room. In fact it is so critical there, that the house can drivee the family apart when it remains unsolved... In modern life, the main function of a family is emotional; it is a source of security and love. But these qualities will only come into existence if the members of the house are physically able to be together as a family. This is often difficult. The various members of the family come and go at different times of day; even when they are in the house, each has his own private interests... In many houses, these interests force people to go off to their own rooms, away from the family. This happens for two reasons. First, in a normal family room, one person can easily be disturbed by what the others are doing... Second, the family room does not usually have any space where people can leave things and not have them disturbed... To solve the problem, there must be some way in which the members of the family can be together, even when they are doing different things. Therefore: Make small places at the edge of any room, usually no more than 6 feet wide and 3 to 6 feet deep and possibly much smaller. These alcoves should be large enough for two people to sit, chat, or play and sometimes large enougf to contain a desk or table. Give the alcove a ceiling which is markedly lower than the ceiling height in the main room... (Alexander, 1977) Programmeringsteknologi, F11 Designmønstre 2. Baggrund og eksempler.9

10 Elementer i et mønster Navn Problem Løsning Konsekvenser Programmeringsteknologi, F11 Designmønstre 2. Baggrund og eksempler.10

11 Et mønsters navn Navn Problem Løsning Konsekvenser Navnet er et håndtag vi kan benytte til i et ord eller to at beskrive et designproblem, dets løsning og konsekvenser. Navngivning at et mønster beriger vores designordforråd og muliggør at vi kan designe på et højere abstraktionsniveau. Navngivning muliggør at vi kan kommunikere om et mønster med kolleger og referere til det i dokumentation. Gode navne hænger ikke på træerne. Programmeringsteknologi, F11 Designmønstre 2. Baggrund og eksempler.11

12 Problemet Navn Problem Løsning Konsekvenser Problemet beskriver hvornår et mønster kan bringes i anvendelse, og beskriver problemets i dets kontekst. Ofte vil problemet omfatte en række betingelser som skal være opfyldt før et mønster kan anvendes. Programmeringsteknologi, F11 Designmønstre 2. Baggrund og eksempler.12

13 Løsningen Navn Problem Løsning Konsekvenser Løsningen beskriver elementerne som indgår i designet, deres relation og samspil. Løsningen beskriver ikke et specifikt, konkret design eller implementation, men derimod hvorledes en samling generelle elementer (i vores verden objekter og klasser) indgår i en generel løsning på problemet. Et mønster er som en skabelon der kan anvendes i mange forskellige situationer. Programmeringsteknologi, F11 Designmønstre 2. Baggrund og eksempler.13

14 Konsekvenser Navn Problem Løsning Konsekvenser Konsekvenserne er resultatet af og trade-offs ved at anvende et mønster. Konsekvenser er vigtige i vurderingen af designalternativer. Konsekvenser er vigtige for at forstå omkostningerne og fordelene ved at anvende et mønster. Man kan skelne mellem kvantitative og kvalitative konsekvenser; kvantitative handler typisk om tradeoffs mellem tid og plads; kvalitative handler typisk om betydningen for fleksibilitet, modificerbarhed og flytbarhed. Programmeringsteknologi, F11 Designmønstre 2. Baggrund og eksempler.14

15 Observer en starter

16 Ur Clock Hour: 11 Min: 38 Sek: 25 MSek:.. is presented as depends on depends on Programmeringsteknologi, F11 Designmønstre 2. Baggrund og eksempler.16

17 Regneark Celler D7: 25 D8: 10 D9: 65 is presented as depends on depends on Lagkagediagram Programmeringsteknologi, F11 Designmønstre 2. Baggrund og eksempler.17

18 CAD-system House DoorA Roof1 Window3 Browser... is presented as depends on depends on Programmeringsteknologi, F11 Designmønstre 2. Baggrund og eksempler.18

19 CASE-værktøj AST Browser... is presented as depends on depends on class Account { public: virtual void deposit(...); virtual void withdraw(...); }; class ChequeAccount : public Account {... };... Programmeringsteknologi, F11 Designmønstre 2. Baggrund og eksempler.19

20 Generelt: Subject-Observers Subject depends on is presented as Observer 1 Observer 2... Observer n Programmeringsteknologi, F11 Designmønstre 2. Baggrund og eksempler.20

21 Problem Ændring af den interne tilstand i en komponent kan bevirke inkonsistens i andre eller på tværs af komponenter. Hvordan kan vi reetablere konsistens således at: informationsudbyderen (subject) ikke afhænger af forbrugerne (observers) forbrugerne (observers) ikke skal være kendt på forhånd. Programmeringsteknologi, F11 Designmønstre 2. Baggrund og eksempler.21

22 Løsning Implementer en change propagation mechanism mellem informationsudbyder (Subject) og forbrugere (Observers). Subject vedligeholder et register over Observers og gør alle Observers opmærksomme på ændringer af tilstand-en. Observer erklærer en (virtuel) update-funktion som kaldes af Subjects change propagation mechanism. Konkrete Observers implementerer updatemetoden... Programmeringsteknologi, F11 Designmønstre 2. Baggrund og eksempler.22

23 Løsning, struktur abstrakt (videre-)binding Programmeringsteknologi, F11 Designmønstre 2. Baggrund og eksempler.23

24 Løsning, dynamik Subject Observer 1 Observer 2 Programmeringsteknologi, F11 Designmønstre 2. Baggrund og eksempler.24

25 Løsning, dynamik Subject Observer 1 Observer 2 attach(this) Programmeringsteknologi, F11 Designmønstre 2. Baggrund og eksempler.25

26 Løsning, dynamik Subject Observer 1 Observer 2 attach(this) attach(this) Programmeringsteknologi, F11 Designmønstre 2. Baggrund og eksempler.26

27 Løsning, dynamik Subject Observer 1 Observer 2 attach(this) attach(this) Programmeringsteknologi, F11 Designmønstre 2. Baggrund og eksempler.27

28 Løsning, dynamik Subject Observer 1 Observer 2 attach(this) attach(this) setdata Programmeringsteknologi, F11 Designmønstre 2. Baggrund og eksempler.28

29 Løsning, dynamik Subject Observer 1 Observer 2 attach(this) attach(this) setdata notify Programmeringsteknologi, F11 Designmønstre 2. Baggrund og eksempler.29

30 Løsning, dynamik Subject Observer 1 Observer 2 attach(this) attach(this) setdata notify update Programmeringsteknologi, F11 Designmønstre 2. Baggrund og eksempler.30

31 Løsning, dynamik Subject Observer 1 Observer 2 attach(this) attach(this) setdata notify update getdata Programmeringsteknologi, F11 Designmønstre 2. Baggrund og eksempler.31

32 Løsning, dynamik Subject Observer 1 Observer 2 attach(this) attach(this) setdata notify update getdata update Programmeringsteknologi, F11 Designmønstre 2. Baggrund og eksempler.32

33 Løsning, dynamik Subject Observer 1 Observer 2 attach(this) attach(this) setdata notify update getdata getdata update Programmeringsteknologi, F11 Designmønstre 2. Baggrund og eksempler.33

34 Løsning, struktur (igen) abstrakt (videre-)binding Programmeringsteknologi, F11 Designmønstre 2. Baggrund og eksempler.34

35 Om softwaremønstre Abstraktioner og sprogmekanismer Gang of Four (GoF) En skabelon for mønstre (eks. Observer)

36 Simulering af abstrakt datatype const N = 10; type T = integer; Stack = record t: array [1.10] of T; sp: 0..N end; procedure init (var s: Stack); function isempty(var s: Stack): boolean; function isfull (var s: Stack): boolean; procedure push (var s: Stack; e: T); procedure pop (var s: Stack; var e: T); Programmeringsteknologi, F11 Designmønstre 2. Baggrund og eksempler.36

37 Brug af abstrakt datatype var s: Stack; x: integer; begin init(s); readln(x); while x<>0 do if not isfull(s) then push(s, x); while not isempty(s) do begin pop(s, x); writeln(x) end end. Programmeringsteknologi, F11 Designmønstre 2. Baggrund og eksempler.37

38 Abstraktioner og sprogmekanismer Sprogmekanismer... Tid Arkitektoniske abstraktioner Programmeringsteknologi, F11 Designmønstre 2. Baggrund og eksempler.38

39 Eksempler goto call return record array class object Tid goto sr a:... s:... goto a Manuel allokering og administration af lagerblokke; manuel adresseberegning ved indeksering,... Simulering af abstrakte datatyper (ADT)? Kræver stor disciplin og systematik af udvikleren. Ingen sprogunderstøttelse. Programmeringsteknologi, F11 Designmønstre 2. Baggrund og eksempler.39

40 Eksempler goto call return record array class object... Tid goto sr a:... s:... goto a Manuel allokering og administration af lagerblokke; manuel adresseberegning ved indeksering,... Simulering af abstrakte datatyper (ADT) Mønstre Programmeringsteknologi, F11 Designmønstre 2. Baggrund og eksempler.40

41 Gang of Four (GoF) Erich Gamma, Richard Helm Ralph Johnson & John Vlissides Design Patterns Elements of Reusable Object-Oriented Software Addison-Wesley, (Også udgivet som CD, 1998) Første systematiske fremstilling af designmønstre (for software). Programmeringsteknologi, F11 Designmønstre 2. Baggrund og eksempler.41

42 Designmønstre Et designmønster - navngiver, - abstraherer og - identificerer de centrale aspekter ved en gængs designstruktur. Et designmønster identificerer deltagende klasser (og instanser) deres rolle og samarbejde samt ansvarsfordelingen mellem dem. The Pattern Community: Aggresive disregard of originality Programmeringsteknologi, F11 Designmønstre 2. Baggrund og eksempler.42

43 Designmønstre i GoF (23 stk.) Creational (5) Structural (7) Behavioral (11) Abstract Factory Builder Factory Method Prototype Singleton Adapter Bridge Composite Decorator Facade Flyweight Proxy Chain of Responsibility Command Interpreter Iterator Mediator Memento Observer State Strategy Template Method Visitor Programmeringsteknologi, F11 Designmønstre 2. Baggrund og eksempler.43

44 Designmønstre á la GoF 1. Introduction 2. A Case Study 3. Creational Patterns (1-5) 4. Structural Patterns (6-12) 5. Behavioral Patterns (13-23) 6. Conclusion - pattern name and classification - intent - also known as - motivation (et eksempel) - applicability - structure (generalisering) - participants - collaborations - consequences - implementation - sample code - known uses - related patterns Programmeringsteknologi, F11 Designmønstre 2. Baggrund og eksempler.44

45 Observer, GoF pp Intent Definerer en en-til-mange sammenhæng mellem objekter så ændringer af tilstanden i et objekt automatisk reflekteres i alle de andre objekter (Publish-Subscribe). Motivation Programmeringsteknologi, F11 Designmønstre 2. Baggrund og eksempler.45

46 Observer (2) Structure Programmeringsteknologi, F11 Designmønstre 2. Baggrund og eksempler.46

47 Observer (3) Participants Subject, kender sine (abstrakte) observere; et vilkårligt antal observere kan knyttes til et subject; giver gennem sit interface mulighed for at tilknytte og fjerne observere Observer, definerer et interface til at opdatere objekter der skal bekendtgøres om ændringer i et subject ConcreteSubject, indkapsler tilstand for konkrete subjects; bekendtgør tilstandsændringer til observere ConcreteObserver, vedligeholder en reference til et ConcreteSubject objekt; indkapsler tilstand der skal være konsistent med subject Programmeringsteknologi, F11 Designmønstre 2. Baggrund og eksempler.47

48 Observer (4) Collaboration Programmeringsteknologi, F11 Designmønstre 2. Baggrund og eksempler.48

49 Observer, Sample Code (1) class Subject; class Observer { // interface public: virtual ~Observer(); virtual void Update(Subject* thechangedsubject) = 0; protected: Observer(); }; class Subject { // abstract class public: virtual ~Subject(); virtual void Attach(Observer*); virtual void Detach(Observer*); virtual void Notify(); protected: Subject(); private: List<Observer*>* observers; }; Programmeringsteknologi, F11 Designmønstre 2. Baggrund og eksempler.49

50 Observer, Sample Code (2) void Subject::Attach(Observer* o) { observers->append(o); } void Subject::Detach(Observer* o) { observers->remove(o); } void Subject::Notify() { ListIterator<Observer*> i(observers); } for (i.first();!i.isdone(); i.next()) i.currentitem()->update(this); Programmeringsteknologi, F11 Designmønstre 2. Baggrund og eksempler.50

51 Observer, Sample Code (3) class ClockTimer : public Subject { public: ClockTimer(); virtual int GetHour(); virtual int GetMinute(); virtual int GetSecond(); }; void Tick(); // Tick kaldes jævnligt af en intern timer void ClockTimer::Tick() { // opdatér den interne repræsentation //... Notify(); } Programmeringsteknologi, F11 Designmønstre 2. Baggrund og eksempler.51

52 Observer, Sample Code (4) class DigitalClock : public Widget, public Observer { public: DigitalClock(ClockTimer*); virtual ~DigitalClock(); virtual void Update(Subject*) // (re-)definerer Observer::Update virtual void Draw(); // (re-)definerer Widget::Draw private: ClockTimer* subject; }; Programmeringsteknologi, F11 Designmønstre 2. Baggrund og eksempler.52

53 Observer, Sample Code (5) DigitalClock::DigitalClock(ClockTimer* s) { subject = s; subject->attach(this); } DigitalClock::~DigitalClock(ClockTimer* s) { subject->detach(this); } void DigitalClock::Update(Subject* ChangedSubject) { if (ChangedSubject == subject) Draw(); } void DigitalClock::Draw() { // skaf de nye værdier fra subject int hour = subject->gethour(); int minute = subject->getminute(); // etc. // tegn det digitale ur } Programmeringsteknologi, F11 Designmønstre 2. Baggrund og eksempler.53

54 Øvelse I Java-kode bliver det naturligvis til to klasser, Order og Item, hvor attributten total i klassen Order af effektivitetshensyn skal være en afledt (beregnet) attribut som overholder følgende invariant: total = ( Σ i 0 i < items.size() : items.get(i).getprice() ) Vi vil naturligvis gerne undgå at inficere klassen Item med beslutningen om at attributten total i klassen Order er afledt. Kort sagt ønsker vi at undgå en afhængighed fra Item til Order. Benyt Observer-mønsteret til at realisere denne afkobling. Programmeringsteknologi, F11 Designmønstre 2. Baggrund og eksempler.54

55 Sammenfatning om mønstre Præsenterer en konkret løsningsstruktur for tilbagevendende designproblemer. Dokumenterer velafprøvede designerfaringer. Specificerer strukturer og begreber over niveauet for de enkelte klasser og objekter. Beskriver struktur og opførsel af samarbejdende objekter. Giver et fælles ordforråd og en fælles begrebsforståelse. Adresserer specifikke kvalitetsegenskaber ved problemets løsning. Programmeringsteknologi, F11 Designmønstre 2. Baggrund og eksempler.55

56 Typisk struktur for mønstr Definerer interface og eventuelt implementation Abstrakt/ deferred klasse Klient Abstrakt/ deferred klasse Konkret klasse Konkret klasse Implmenterer interfacet fra superklassen (m.m.) Tilføjer evt. ny funktionalitet som gensidigt kan benyttes Programmeringsteknologi, F11 Designmønstre 2. Baggrund og eksempler.56

57 Et mønster er både produkt og proces Ethvert mønster fortæller hvad man skal gøre, dvs. hvilken struktur der skal skabes og hvilken opførsel der skal være i denne struktur. Et mønster fortæller hvordan man skal benytte det ved at beskrive en proces som hjælper med at skabe strukturen. Eksempel: Observer Identificer Subject og Observers Tilføj registreringsfunktionalitet til Subject Tilføj Observer-repository til Subject Tilføj update-funktionalitet til Observers Implementer Subjects change propagation mechanism Programmeringsteknologi, F11 Designmønstre 2. Baggrund og eksempler.57

58 Mønstre er generiske To implementationer af et mønster er sandsynligvis forskellige. Et mønster giver en generisk løsning (en løsningsstruktur); mønsteret er ikke hugget i sten. Et mønster er et mentalt designværktøj; man kan benytte en løsningsstruktur igen og igen hvor hver implementation er forskellig, men alle deler den samme kerne. Et mønster introducerer roller, IKKE klasser! (En klasse kan ofte spille roller i flere mønstre.) Programmeringsteknologi, F11 Designmønstre 2. Baggrund og eksempler.58

59 Fin... Programmeringsteknologi, F11 Designmønstre 2. Baggrund og eksempler.59