Præsentation er lastning. Vent venligst

Præsentation er lastning. Vent venligst

Designmønstre Baggrund og eksempler Michael E. Caspersen

Lignende præsentationer


Præsentationer af emnet: "Designmønstre Baggrund og eksempler Michael E. Caspersen"— Præsentationens transcript:

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

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

5 Eller en pumpe? 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. 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. Programmeringsteknologi, F11 Designmønstre

6 Fra arkitekturmønstre ...
Christopher Alexander Notes on the Synthesis of Form (1964) The Oregon Experiment (1975) A Pattern Language: Towns, Buildings, Constructions (1977) The Timeless Way of Building (1979) 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. Programmeringsteknologi, F11 Designmønstre

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

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 bygning-er, 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

9 “Alcoves”: et af Alexanders mønstre
... 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

10 Elementer i et mønster Navn Problem Løsning Konsekvenser
Programmeringsteknologi, F11 Designmønstre

11 Navn Problem Løsning Konsekvenser Et mønsters navn 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

12 Navn Problem Løsning Konsekvenser Problemet 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

13 Navn Problem Løsning Konsekvenser Løsningen 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

14 Navn Problem Løsning Konsekvenser 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 trade-offs mellem tid og plads; kvalitative handler typisk om betydningen for fleksibilitet, modificerbarhed og flytbarhed. Programmeringsteknologi, F11 Designmønstre

15 Observer – en starter

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

17 Regneark Celler D7: 25 D8: 10 D9: 65 is presented as depends on
Lagkage- diagram Programmeringsteknologi, F11 Designmønstre

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

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

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

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

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 update-metoden... Programmeringsteknologi, F11 Designmønstre

23 Løsning, struktur abstrakt (videre-)binding
Programmeringsteknologi, F11 Designmønstre

24 Løsning, dynamik Subject Observer 1 Observer 2
Programmeringsteknologi, F11 Designmønstre

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

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

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

28 Løsning, dynamik Subject Observer 1 Observer 2 attach(this) setData
Programmeringsteknologi, F11 Designmønstre

29 Løsning, dynamik Subject Observer 1 Observer 2 attach(this) setData
notify Programmeringsteknologi, F11 Designmønstre

30 Løsning, dynamik Subject Observer 1 Observer 2 attach(this) setData
notify update Programmeringsteknologi, F11 Designmønstre

31 Løsning, dynamik Subject Observer 1 Observer 2 attach(this) setData
notify update getData Programmeringsteknologi, F11 Designmønstre

32 Løsning, dynamik Subject Observer 1 Observer 2 attach(this) setData
notify update getData update Programmeringsteknologi, F11 Designmønstre

33 Løsning, dynamik Subject Observer 1 Observer 2 attach(this) setData
notify update getData update getData Programmeringsteknologi, F11 Designmønstre

34 Løsning, struktur (igen)
abstrakt (videre-)binding Programmeringsteknologi, F11 Designmønstre

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

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

38 Abstraktioner og sprogmekanismer
Tid ... Arkitektoniske abstraktioner Programmeringsteknologi, F11 Designmønstre

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

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

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

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

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

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

45 Observer, GoF pp. 293-303 Intent Motivation
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

46 Observer (2) Structure Programmeringsteknologi, F11 Designmønstre

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

48 Observer (4) Collaboration Programmeringsteknologi, F11 Designmønstre

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 virtual ~Subject(); virtual void Attach(Observer*); virtual void Detach(Observer*); virtual void Notify(); protected: Subject(); private: List<Observer*>* observers; Programmeringsteknologi, F11 Designmønstre

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

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

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

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

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

55 Sammenfatning om mønstre
Præsenterer en konkret løsningsstruktur for tilbage-vendende 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

56 Typisk struktur for mønstr
Definerer interface og eventuelt implementation Klient Abstrakt/ deferred klasse 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

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

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

59 Fin ... Programmeringsteknologi, F11 Designmønstre


Download ppt "Designmønstre Baggrund og eksempler Michael E. Caspersen"

Lignende præsentationer


Annoncer fra Google