Præsentation er lastning. Vent venligst

Præsentation er lastning. Vent venligst

Objektorienteret analyse og design Ó Bennedsen 2001 Designmønstre 8.1 Programmering og systemudvikling Lektion 8 Designmønstre.

Lignende præsentationer


Præsentationer af emnet: "Objektorienteret analyse og design Ó Bennedsen 2001 Designmønstre 8.1 Programmering og systemudvikling Lektion 8 Designmønstre."— Præsentationens transcript:

1 Objektorienteret analyse og design Ó Bennedsen 2001 Designmønstre 8.1 Programmering og systemudvikling Lektion 8 Designmønstre

2 Objektorienteret analyse og design Ó Bennedsen 2001 Designmønstre 8.2 Observer – en starter

3 Objektorienteret analyse og design Ó Bennedsen 2001 Designmønstre 8.3 Ur is presented as depends on Clock Hour: 11 Min: 38 Sek: 25 MSek:..

4 Objektorienteret analyse og design Ó Bennedsen 2001 Designmønstre 8.4 Regneark is presented as depends on Celler D7: 25 D8: 10 D9: 65 Lagkage- diagram

5 Objektorienteret analyse og design Ó Bennedsen 2001 Designmønstre 8.5 CAD-system is presented as depends on House DoorA Roof1 Window3 Browser...

6 Objektorienteret analyse og design Ó Bennedsen 2001 Designmønstre 8.6 CASE-værktøj class Account { public void deposit(...); public void withdraw(...); }; class ChequeAccount extends Account {... };... is presented as AST depends on Browser...

7 Objektorienteret analyse og design Ó Bennedsen 2001 Designmønstre 8.7 Generelt: Subject-Observers Subject Observer 1Observer 2Observer n... depends on is presented as

8 Objektorienteret analyse og design Ó Bennedsen 2001 Designmønstre 8.8 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.

9 Objektorienteret analyse og design Ó Bennedsen 2001 Designmønstre 8.9 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...

10 Objektorienteret analyse og design Ó Bennedsen 2001 Designmønstre 8.10 Løsning, struktur abstract (videre-)binding

11 Objektorienteret analyse og design Ó Bennedsen 2001 Designmønstre 8.11 Løsning, dynamik SubjectObserver 1Observer 2 attach(this) setData notify update getData update getData

12 Objektorienteret analyse og design Ó Bennedsen 2001 Designmønstre 8.12 Om mønstre Abstraktioner og sprogmekanismer Gang of Four (GoF) En skabelon for mønstre (eks. Observer)

13 Objektorienteret analyse og design Ó Bennedsen 2001 Designmønstre 8.13 Abstraktioner og sprogmekanismer Arkitektoniske abstraktioner Sprogmekanismer Tid...

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

15 Objektorienteret analyse og design Ó Bennedsen 2001 Designmønstre 8.15 Eksempler call return Tid record array class object goto goto sr a:... s:... goto a Simulering af abstrakte datatyper (ADT) Manuel allokering og administration af lagerblokke; manuel adresse- beregning ved indeksering,... Mønstre...

16 Objektorienteret analyse og design Ó Bennedsen 2001 Designmønstre 8.16 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.

17 Objektorienteret analyse og design Ó Bennedsen 2001 Designmønstre 8.17 Designmønstre The Pattern Community: Aggresive disregard of originality 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.

18 Objektorienteret analyse og design Ó Bennedsen 2001 Designmønstre 8.18 Designmønstre i GoF (23) Creational (5)Structural (7)Behavioral (11) Abstract Factory Adapter Chain of Responsibility BuilderBridgeCommand Factory Method Composite Interpreter PrototypeDecoratorIterator Singleton FacadeMediator FlyweightMemento ProxyObserver State Strategy Template Method Visitor

19 Objektorienteret analyse og design Ó Bennedsen 2001 Designmønstre 8.19 Designmønstre á la PiJ - synopsis - context - forces - solution - consequences - implementation - Java API usage - code example - related patterns 1. Introduction 2. A Case Study 3. Fundemental Patterns (4) 4. Creational Patterns (5) 5. Partitioning Patterns (6) 6. Structural Patterns (7) 7. Behavioral Parrerns (8) 8. Concurrency Patterns (9) 6. Conclusion

20 Objektorienteret analyse og design Ó Bennedsen 2001 Designmønstre 8.20 Observer 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

21 Objektorienteret analyse og design Ó Bennedsen 2001 Designmønstre 8.21 Observer (2) Structure

22 Objektorienteret analyse og design Ó Bennedsen 2001 Designmønstre 8.22 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

23 Objektorienteret analyse og design Ó Bennedsen 2001 Designmønstre 8.23 Observer (4) Collaboration

24 Objektorienteret analyse og design Ó Bennedsen 2001 Designmønstre 8.24 Observer, Sample Code (1) interface Observer { public abstract void update(Subject theChangedSubject); }; abstract class Subject { public void attach(Observer o) {observers.add(o);} public void Detach(Observer o) {observers.remove(o);} public void notify() {…}; protected Subject(); private List observers; };

25 Objektorienteret analyse og design Ó Bennedsen 2001 Designmønstre 8.25 Observer, Sample Code (2) public void notify() { iterator i = observers.iterator(); while (i.hasNext()) (Observer)(i.next()).update(this); }

26 Objektorienteret analyse og design Ó Bennedsen 2001 Designmønstre 8.26 Observer, Sample Code (3) class ClockTimer extends Subject { public ClockTimer(); public int getHour(); public int getMinute(); public int getSecond(); void tick(); // Tick kaldes jævnligt af en intern timer }; void ClockTimer::tick() { // opdatér intern repræsentation //... notify(); }

27 Objektorienteret analyse og design Ó Bennedsen 2001 Designmønstre 8.27 Observer, Sample Code (4) class DigitalClock implements Widget extends Observer { public DigitalClock(ClockTimer); public void update(Subject) // (re-)definerer Observer::update public void draw(); // (re-)definerer Widget::draw private ClockTimer _subject; };

28 Objektorienteret analyse og design Ó Bennedsen 2001 Designmønstre 8.28 Observer, Sample Code (5) DigitalClock::DigitalClock(ClockTimer s) { _subject = s; _subject.attach(this); } DigitalClock::finalize() { _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 }

29 Objektorienteret analyse og design Ó Bennedsen 2001 Designmønstre 8.29 Iterator Intent Giver sekventiel tilgang til elementerne i en container (et aggregat) uden at afsløre containerens underliggende repræsentation. Motivation Problemstillingen og et bud på en løsning er velkendt:

30 Objektorienteret analyse og design Ó Bennedsen 2001 Designmønstre 8.30 Iterator (2) Motivation, fortsat Imidlertid er det ufleksibelt at en klient skal vide at det er en liste der itereres på, men det kan undgås:

31 Objektorienteret analyse og design Ó Bennedsen 2001 Designmønstre 8.31 Iterator (3) Structure CreateIterator er et eksempel på en Factory Method (GoF, pp. 107-116).

32 Objektorienteret analyse og design Ó Bennedsen 2001 Designmønstre 8.32 Composite Intent Sammensæt objekter i en rekursiv træstruktur der repræsenterer et part- whole hierarki. Mønsteret muliggør at enkelte og sammensatte elementer kan behandles uniformt. Motivation

33 Objektorienteret analyse og design Ó Bennedsen 2001 Designmønstre 8.33 Composite (2) Structure

34 Objektorienteret analyse og design Ó Bennedsen 2001 Designmønstre 8.34 Composite (3) Participants Component (Graphic) - erklærer et interface for objekter i strukturen - implementerer standardopførsel for alle objekter - erklærer et interface til “child“-komponenter (evt.) - erklærer et interface til “parent”-komponenter. Leaf (Rectangle, Line, Text, etc.) - repræsenterer primitive objekter (blade) - (re-)definerer opførsel for primitive objekter....

35 Objektorienteret analyse og design Ó Bennedsen 2001 Designmønstre 8.35 Composite (4) Participants, fortsat Composite (Picture) - (re-)definerer opførsel for sammensatte objekter - gemmer referencer til efterfølgerobjekter - implementerer efterfølger-relaterede operationer fra interfacet. Client - manipulerer Component-objekter gennem Component- interfacet.

36 Objektorienteret analyse og design Ó Bennedsen 2001 Designmønstre 8.36 Composite (5) Implementation... Skal operationer til håndtering af sammensatte objekter erklæres i Component eller i Composite? Svaret forudsætter en afvejning mellem sikkerhed og transparens; i dette designmønster er transparens fundet vigtigere end sikkerhed, men bemærk at det er i konflikt med substitutionsprincippet. Hvis operationerne flyttes ned i Composite, opstår der i Client behov for på runtime at kunne spørge på typen af et Component-objekt. I C++ kan man bruge dynamic_cast eller tilføje en operation getComposite i Component-interfacet:

37 Objektorienteret analyse og design Ó Bennedsen 2001 Designmønstre 8.37 Composite, sikkerhed over transparens class Component { public: //... Composite getComposite() { return null; } }; class Composite extends Component { public: add(Component); remove(Component); //... Composite getComposite() { return this; } }; class Leaf extends Component { //... }

38 Objektorienteret analyse og design Ó Bennedsen 2001 Designmønstre 8.38 Template Method, GoF pp. 325-330 Intent At definere grundstrukturen i en algoritme, men udskyde den konkrete fastlæggelse af enkelte trin til subklasser. Subklasser kan redefinere elementer i en algoritme, men grundstrukturen ligger fast. Motivation

39 Objektorienteret analyse og design Ó Bennedsen 2001 Designmønstre 8.39 Template Method (2) Class Application { public void OpenDocument(String name) { if ( !CanOpenDocument(name) ) { // cannot handle this document return; } Document doc = DoCreateDocument(); if ( doc ) { _docs.AddDocument(doc); AboutToOpenDocument(doc); doc.Open(); doc.DoRead(); } private Vector _docs; }

40 Objektorienteret analyse og design Ó Bennedsen 2001 Designmønstre 8.40 Template Method (3) class Shape { public Shape(int x, int y) _x(x), _y(y) {} public void move(int dx, int dy) { hide(); _x+= dx; _y+= dy; show(); } public abstract void show(); public abstract void hide(); protected int _x; protected int _y; }; Operationen ’move’ i et figurhierarki er en Template Method:

41 Objektorienteret analyse og design Ó Bennedsen 2001 Designmønstre 8.41 Template Method (4) Structure

42 Objektorienteret analyse og design Ó Bennedsen 2001 Designmønstre 8.42 Adapter, GoF pp. 139-150 Intent Konverterer interfacet for en klasse til et som klinten forventer (wrapper, late abstraction). Motivation Det kan ske at en klasse er svær at genbruge fordi den har et “forkert” interface (eks.: Vector og List burde kunne behandles uniform, men har forskellige interfaces). Eller: Til et tegneprogram kan det være ligetil at implementere klasserne Shape, LineShape, PolygonShape, hvorimod TextShape er noget mere kompliceret; selv basal teksteditering involverer komplicerede skærm- opdateringer og buffer-håndtering.

43 Objektorienteret analyse og design Ó Bennedsen 2001 Designmønstre 8.43 Adapter, Motivation fortsat Imidlertid findes der en ‘off-the-shelf’ klasse, TextView; problemet er blot at denne ikke er designet – og derfor ikke kan behandles – som en Shape. Hvis vi har kildeteksten til TextView kan vi ændre interfacet så det passer til Shape, men ofte har man ikke kildeteksten, og selv om man har, er det af hensyn til andre applikationer ikke ønskeligt at tilpasse interfacet. Men vi kan definere TextShape som en adapter der tilpasser TextViews interface til Shape-hierarkiet. Dette kan gøres på to måder: Class Adapter Object Adapter

44 Objektorienteret analyse og design Ó Bennedsen 2001 Designmønstre 8.44 Adapter public class Shape { // BoundingBox-based public Shape(){…} public Box BoundingBox(); public Manipulator CreateManipulator(); }; class TextView { // OriginAndExtent-based public: TextView(); //returnerer centrum public point GetOrigin(Coord& x, Coord& y){…} //retrunerer bredde og højde public pair GetExtent(){…} public bool isEmpty(){…} };

45 Objektorienteret analyse og design Ó Bennedsen 2001 Designmønstre 8.45 Class Adapter (C++ style) class TextShape : public Shape, private TextView { public: TextShape(); virtual void BoundingBox(Point& bottomLeft, Point& topRight); virtual bool isEmpty(); virtual Manipulator* CreateManipulator(); }; void TextShape::BoundingBox(Point& bottomLeft, Point& topRight) { Coord bottom, left, width, height; GetOrigin(bottom, left); GetExtent(width, height); bottomLeft = Point(bottom, left); topRight = Point(bottom + height, left + width); }

46 Objektorienteret analyse og design Ó Bennedsen 2001 Designmønstre 8.46 Adapter for containerklasser template class Vector { public: explicit Vector(size_t n); T& operator[](size_t); }; template class List { public: class Link {... }; List(); void put(T*); T* get(); }; Hver klasse tilbyder ”de naturlige operationer” – de er små og kan inlines (effektivt) – og for hver klasse kan vi vælge en passende repræsentationsinvariant uden at tænke på de øvrige containere. Imidlertid kan forekomster af de to forskellige slags containerklassser ikke behandles uniformt (for eksem- pel med en iterator), og det er træls! Hvad gør vi?

47 Objektorienteret analyse og design Ó Bennedsen 2001 Designmønstre 8.47 Wrap, wrap, and abstract wrap abstract Late Abstraction

48 Objektorienteret analyse og design Ó Bennedsen 2001 Designmønstre 8.48 Koden... template class VectorItor : public Itor { public: VectorItor(Vector & vv) : v(vv), index(0) {} T* first() {... } T* next() {... } private: Vector & v; size_t index; }; template class ListItor : public Itor { public: ListItor(List & llst) : lst(llst),... {} T* first() {... } T* next() {... } private: List & lst; List ::Link p; }; template class Itor { public: virtual T* first()= 0; virtual T* next()= 0; };

49 Objektorienteret analyse og design Ó Bennedsen 2001 Designmønstre 8.49 Anvendelser int count (Itor & i, int x) { int c = 0; for ( int* p=i.first(); p; p=i.next() ) if ( *p==x ) c++; return c; } Vector v; VectorItor vi(v); int periodCount = count(vi, 7); List l; ListItor li(v); int commaCount = count(li, 42); Operationerne first() og next() er simple, men de giver et overhead i form af et virtuelt funktionskald. Til et standardbibliotek er det ikke ideelt, men løsningen har dog været brugt i et utal af systemer, og i mange år var det faktisk Bjarne Stroustrups favoritløsning. Lige indtil Alexander Stepanov og Meng Lee fra HP kom med STL...

50 Objektorienteret analyse og design Ó Bennedsen 2001 Designmønstre 8.50 Hvad vi lærte af “Late Abstraction” Bemærk: Et fælles interface som Itor kan laves længe efter at containerklasserne er designet og implementeret. Når vi designer og program- merer, udvikler vi typisk først noget meget konkret (for ek- sempel Vector og List ). Først senere erkender vi ab- straktioner der kan generali- sere de mere konkrete kom- ponenter (f. eks. Itor ). ”Late abstraction” kan vi benytte gentagne gange. ”Late abstraction” vha. abstrakte klasser tillader os at lave forskellige implementa- tioner af et begreb også når der ikke er en åbenlys lighed mellem implementationerne. Vector og List har oplagte fællestræk, men der er ikke noget i vejen for også at lave en Itor for eksempelvis en stream.

51 Objektorienteret analyse og design Ó Bennedsen 2001 Designmønstre 8.51 Factory method è Frameworks bruger abstrakte klasser til at definere og vedligeholde sammenhæng mellem objekter. Et framework har ofte ansvaret for at oprette disse objekter. è Dette gælder for eksempel Collection frameworket i java

52 Objektorienteret analyse og design Ó Bennedsen 2001 Designmønstre 8.52 Factory Method

53 Objektorienteret analyse og design Ó Bennedsen 2001 Designmønstre 8.53 Struktur

54 Objektorienteret analyse og design Ó Bennedsen 2001 Designmønstre 8.54 struktur è Product (TIterator) –defines the interface of objects the factory method creates. è ConcreteProduct (TKundeIterator) –implements the Product interface. è Creator (TContainer) –declares the factory method, which returns an object of type Product. Creator may also define a default implementation of the factory method that returns a default ConcreteProduct object. –may call the factory method to create a Product object. è ConcreteCreator (TKundeContainer) –overrides the factory method to return an instance of a ConcreteProduct.

55 Objektorienteret analyse og design Ó Bennedsen 2001 Designmønstre 8.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.

56 Objektorienteret analyse og design Ó Bennedsen 2001 Designmønstre 8.56 Typisk struktur for et mønster Klient Abstrakt/ deferred klasse Konkret klasse Abstrakt/ deferred klasse Konkret klasse Definerer interface og eventuelt implementation Implmenterer interfacet fra superklassen (m.m.) Tilføjer evt. ny funktionalitet som gensidigt kan benyttes

57 Objektorienteret analyse og design Ó Bennedsen 2001 Designmønstre 8.57 Et mønster er både en proces og en ting è 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”

58 Objektorienteret analyse og design Ó Bennedsen 2001 Designmønstre 8.58 Mønstre er generiske è To implementationer af et mønster er sandsynligvis for-skellige. è Et mønster giver en generisk løsning (en løsningsstruk-tur); 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 implementa-tion 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.)

59 Objektorienteret analyse og design Ó Bennedsen 2001 Designmønstre 8.59 Opsamling

60 Objektorienteret analyse og design Ó Bennedsen 2001 Designmønstre 8.60 Syn Grænseflade Interaktion Livsforløb Funktionalitet Arkitektur Begreber

61 Objektorienteret analyse og design Ó Bennedsen 2001 Designmønstre 8.61 “De fire skyer” Analyse Realiserede begreber Teknisk “virkelighed” Problem specifikke begreber Vision/ idé Design Realisering Genstandsområde Modelsystem

62 Objektorienteret analyse og design Ó Bennedsen 2001 Designmønstre 8.62 Proces Class Odder {... };

63 Objektorienteret analyse og design Ó Bennedsen 2001 Designmønstre 8.63 Design versus Analyse è Applikationen è Abstraktioner è Formalisering è Intern grænseflade è  è  è   è 

64 Objektorienteret analyse og design Ó Bennedsen 2001 Designmønstre 8.64 Objektorienteret design There are many possible activities and artifacts in analysis and design, and a wealth of principles and guidelines. Suppose we must choose a single practical skill from all the topics discussed here – a ”dessert island” skill. What would it be? Why? Because it is the one activity which must be performed (it is inescapable) and it has the most profound effect on the robustness, maintainability, and reuseability of software components. Craig Larman, 1998 Applying UML and Patterns – An Introduction to Object-Oriented Analysis and Design The most single important ability in object- oriented analysis and design is to skillfully assign responsibilities to software components.


Download ppt "Objektorienteret analyse og design Ó Bennedsen 2001 Designmønstre 8.1 Programmering og systemudvikling Lektion 8 Designmønstre."

Lignende præsentationer


Annoncer fra Google