Ohjelmistotuotannon menetelmät Syksy 2003

1. Ohjelmistotuotannon menetelmätSyksy 2003 Design Patterns (Sami Jantunen, LTY/TITE)

2. Ohjelma • Design Patterneista Yleisesti • Historiatietoa • Määrittely • Ominaisuuksia • Design Patternien kuvaustavat • Patterntyypit • Patternkieli, systeemi, kataloogi • Design patternien käyttö oliopohjaisen järjestelmän kehityksessä • AntiPattern • Esimerkkejä Design Patterneista • Creational Patterns • Structural Patterns • Behavioral Patterns

3. Luettavaa Design Patterns Elements of Reusable Object-Oriented Software by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides (The Gang of Four).

4. Historiatietoa • Arkkitehti Christopher Alexanderin kirjoitukset 1970-luvun lopulla. • “ajattomien” hyväksi todettuja ratkaisuja etsintä talojen suunnittelussa  termi Pattern • Pattern ajattelun omaksuminen ohjelmistotuotannon alalla 1980-luvun lopussa • Kent Beck and Ward Cunningham, Textronix, OOPSLA'87(käytti Alexander's "pattern" ideaa Smalltalkin GUI suunnittelussa) • Erich Gamma, Ph. D. väitöskirja, 1988-1991 • James Coplien, Advanced C++ Idioms kirja, 1989-1991 • Gamma, Helm, Johnson, Vlissides ("Gang of Four“ - GoF)Design Patterns: Elements of Reusable Object-Oriented Software, 1991-1994

5. Design Patterns määrittely • … a fully realized form, original, or model accepted or proposed for imitation…[dictionary] • ... 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 [Alexander] • … the abstraction from a concrete form which keeps recurring in specific non-arbitrary contexts [Riehle] • …both a thing and the instructions for making the thing [Coplien] • ...a literary format for capturing the wisdom and experience of expert designers, and communicating it to novices

6. Patternien ominaisuuksia Patternit… • tarjoaa yhteisen sanaston kuvaamaan ratkaisumalleja tiettyihin ongelmiin • tehostaa kommunikaatiota monimutkaisten järjestelmien suunnittelussa • auttaa arkkitehtuurin dokumentoinnissa Patternit eivät... • tarjoa eksaktia ratkaisua • ratkaise kaikkia suunnitteluongelmia • rajoitu pelkästään oliokeskeiseen suunnittelutyöhön

7. Esimerkki: The Courtyard Pattern – Christopher Alexander “Consider the forces at work in a courtyard. Most fundamental of all, people seek some kind of private outdoor space, where they can sit under the sky, see the stars, enjoy the sun, perhaps plant flowers. This is obvious. But there are more subtle forces too. For instance, when a courtyard is too tightly enclosed, has no view out, people feel uncomfortable, and tend to stay away … they need to see out into some larger and more distant space. Or again, people are creatures of habit. If they pass in and out of the courtyard, every day, in the course of their normal lives, the courtyard becomes familiar, a natural place to go … and it is used. But a courtyard with only one way in, a place you only go when you “want” to go there, is an unfamiliar place, tends to stay unused … people go more often to places which are familiar. Or again, there is a certain abruptness about suddenly stepping out, from the inside, directly to the outside … it is subtle, but enough to inhibit you. If there is a transitional space, a porch or a veranda, under cover, but open to the air, this is psychologically half way between indoors and outdoors, and makes it much easier, more simple, to take each of the smaller steps that brings you out into the courtyard”

8. The Courtyard Pattern jatkoa…(johtopäätös) “When a courtyard has a view out to a larger space has crossing paths from different rooms has a veranda or a porch these forces can resolve themselves. The view out makes it comfortable, the crossing paths help generate a sense of habit there, the porch makes it easier to go out more often … and gradually the courtyard becomes a pleasant customary place to be.”

9. Patternin sisältö “Courtyard” esimerkki… • Identifioi patternin • Kuvasi asiat mitä tulisi tavoitella • Kuvasi miten tavoite voitaisiin saavuttaa • Kertoi voimista, mitkä saattaisi vahingoittaa toivottua tavoitetta

10. Patternin rakenne Alexanderin tyyli (canonical form) Namemeaningful name Problemthe statement of the problem Contexta situation giving rise to a problem Forcesa description of relevant forces and constraints Solutionproven solution to the problem Examples sample applications of the pattern Resulting context (force resolution)the state of the system after pattern has been applied Rationale explanation of steps or rules in the pattern Related patternsstatic and dynamic relationship Known useoccurrence of the pattern and its application within existing system

11. Patternin rakenne GoF tyyli Pattern name and classification Intent what does pattern do / when the solution works Also known as other known names of pattern (if any) Motivation the design problem / how class and object structures solve the problem Applicability situations where pattern can be applied Structure a graphical representation of classes in the pattern Participants the classes/objects participating and their responsibilities Collaborations of the participants to carry out responsibilities Consequences trade-offs, concerns Implementation hints, techniques Sample code code fragment showing possible implementation Known usespatterns found in real systems Related patterns closely related patterns

12. Pattern-tyyppejä Creational Patterns • tekee järjestelmistä riippumattomampia olioiden luontitavasta. Structural Patterns • Luokkien ja olioiden kokoaminen suuremmiksi rakenteiksi. Behavioral Patterns • Algoritmien ja olioiden välisten vastuiden määrittely.

13. Pattern catalogs and systems [Buschmann, POSA] • pattern catalog …a collection of related patterns, where patterns are subdivided into small number of broad categories… • pattern system …a cohesive set of related patterns, which work together to support the construction and evolution of hole architectures...

14. Design pattern luettelo (Gang of Four) Patterneita kuvattu esim: http://pages.cpsc.ucalgary.ca/~kremer/patterns/

15. Patternien käyttö luokkakaaviossa-Vaikeudet ja riskit Patternit eivät ole patenttiratkaisu: • Älä käytä patterneja suin päin. Patternien soveltaminen voi johtaa huonoihin ratkaisuihin. • Ymmärrä aina syvällisesti seikat mitkä pitää ratkaista ja mikä pattern ratkaisee kyseiset ongelmat • Pidä huolta, että perustelet jokaisen suunnittelupäätöksen huolellisesti

16. AntiPattern • AntiPattern kertoo kuinka ongelma ratkaistaan huonosti • Hyvä AntiPattern kertoo: • miksi huono ratkaisu näyttää houkuttelevalta • miksi ratkaisu osoittautuu lopulta huonoksi • mitä Patternia kannattaisi käyttää ongelman ratkaisuun • “an anti-pattern is something that looks like a good idea, but which backfires badly when applied.” (Jim Coplien)

17. Antipatternesimerkki: ZeroMeansNull Name:ZeroMeansNull Type: Design Category:AntiPattern Problem: Implementing an optional field. Forces: Laziness or optimism. Ignorance of nulls, e.g. "they're too inconvenient to deal with". Using a storage implementation that doesn't support them. Supposed solution: Nobody will ever set this to all zeros, so let that represent "omitted." Resulting context: When it really needs to be zero, it can't be. When you need to convert from ints to some form of real, you can't reliably detect zero (RealNumbersAreNotEqual). You can forget to compare with zero in some cases, and let it through as a nonsense value. You're more likely to get an exception (e.g. NullPointerException in Java) if you use a proper null. Example: Designer thinks "Nobody will ever be at latitude zero, longitude zero." User reports:"I hope you can help me! I'm trying to draw grid lines on the globe and for some reason one is always missing...." Lisää antipatterneja: http://c2.com/cgi/wiki?AntiPatternsCatalog

18. Missä mennään? • Design Patterneista Yleisesti • Historiatietoa • Määrittely • Ominaisuuksia • Design Patternien kuvaustavat • Patterntyypit • Patternkieli, systeemi, kataloogi • Design patternien käyttö oliopohjaisen järjestelmän kehityksessä • AntiPattern • Esimerkkejä Design Patterneista • Creational Patterns • Structural Patterns • Behavioral Patterns

19. Esimerkki:Tietokonepeli Haluaisimme luoda labyrintin tietokonepeliin… Alustava ratkaisu:

20. Luokkien määrittely MapSite-luokka on yhteinen abstrakti isäluokka kaikkiin labyrinttiin kuuluviin luokkiin. Class MapSite { public: virtualvoid Enter() = 0; }; • Enter-metodin tarkoitus riippuu siitä mihin ollaan labyrintissä astumassa sisään

21. Jatkoa luokkien määrittelyyn... Enum Direction {North, South, East, West}; Class Room : public MapSite { public: Room(int roomNo); MapSite* Side(Direction) const; void Set_side(Direction, MapSite*); virtualvoid Enter() { //… } private: MapSite* _sides[4]; int _roomNo; };

22. Jatkoa luokkien määrittelyyn... Jokaisessa huoneessa on 0-4 seinää ja 0-4 ovea. Class Wall : public MapSite { public: Wall(); virtual void Enter() { /… } };

23. Jatkoa luokkien määrittelyyn... Jokainen ovi on kahden huoneen välissä: class Door : public MapSite { public: Door(Room* = NULL, Room* = NULL); virtualvoid Enter() { //… } Room* Other_side_from(Room*); private: Room* _room1; Room* _room2; bool _isOpen; };

24. Jatkoa luokkien määrittelyyn... Maze (labyrintti) -luokka koostuu kokoelmasta huoneita: class Maze { public: Maze(); void Add_room(Room*); Room* RoomNo(int) const; private: List rooms; //List of Room* };

25. Labyrintin kokoaminen Maze* Maze_game::Create_maze () { Maze* maze = new Maze; Room* r1 = new Room(1); Room* r2 = new Room(2); Door* door = new Door(r1, r2); maze->Add_room(r1); maze->Add_room(r2); r1->Set_side(North, new Wall); r1->Set_side(East, door); r1->Set_side(South, new Wall); r1->Set_side(West, new Wall); r2->Set_side(North, new Wall); r2->Set_side(East, new Wall); r2->Set_side(South, new Wall); r2->Set_side(West, door); return maze; } Implementoidaan Maze_game –luokka joka luo labyrintin. Labyrintti voidaan luoda sarjalla operaatioita, missä olioita lisätään labyrinttiin yksi kerrallaan ja kytketään niitä sitten yhteen. Esimerkki: Luodaan 2 hengen labyrintti

26. Ongelma JOUSTAMATTOMUUS • Labyrintti on kovakoodattu • Labyrintin muuttaminen merkitsisi käytännössä uusiksi ohjelmoimista

27. Labyrintin jatkokehitys… Mitä jos haluttaisiin käyttää hyväksi vanhaa labyrinttiä ja jatkokehittää sitä seuraavilla luokilla: • Door_needing_spell– Ovi, joka sulkeutuu tai avautuu loitsun avulla. • Enchanted_room– Huone, jossa on epätavallisia esineitä.

28. Labyrintin uudelleenkäytön parantelu… Olemassa oleva koodi tulisi muuttaa sellaiseksi, että uuden tyyppisten olioiden luominen tapahtuisi mahdollisimman pienin koodimuutoksin? • Annetaan Create_maze:en parametrina olio, jonka tehtävänä on luoda huoneet, seinät ja ovet Määritellään ensin Maze_factory–luokka, joka luo labyrintin osaset ajonaikana. Class Maze_factory { public: Maze_factory(); // the following are also called “virtual constructor”. virtual Maze* Make_maze() const { returnnew Maze; } virtual Wall* Make_wall() const { return new Wall; } virtual Room* Make_room(int n) const { return new Room(n); } virtual Door* Make_door(Room* r1, Room* r2) const { return new Door(r1, r2); } };

29. Parannetaan Create_maze -metodia Maze* Maze_game::Create_maze(Maze_factory& factory) { Maze* maze = factory.Make_maze(); Room* r1 = factory.Make_room(1); Room* r2 = factory.Make_room(2); Door* door = factory.Make_door(r1, r2); maze->Add_room(r1); maze->Add_room(r2); r1->Set_side(North, factory.Make_wall()); r1->Set_side(East, door); r1->Set_side(South, factory.Make_wall()); r1->Set_side(West, factory.Make_wall()); r2->Set_side(North, factory.Make_wall()); r2->Set_side(East, factory.Make_wall()); r2->Set_side(South, factory.Make_wall() ); r2->Set_side(West, door); return maze; }

30. Ja palataan sitten parannellun labyrintin pariin…. Luodaan Enchanted_maze_factory–luokka perimällä se Maze_factory:sta. Tämä luokka yliajaa jäsenfunktiot ja palauttaa erilaiset Room- Wall, … -oliot Class Enchanted_maze_factory : public Maze_factory { public: Enchanted_maze_factory (); virtual Room* Make_room(int n) const { returnnew Enchanted_room(n, Cast_spell()); } virtual Door* Make_door(Room* r1, Room* r2) const { returnnew Door_needing_spell(r1, r2);} protected: Spell* Cast_spell() const; };

31. Labyrintin rakentaminen Maze_game game; Enchanted_maze_factory factory; game.create_maze(factory); Tällä tavalla voimme luoda minkälaisen labyrintin tahansa!

32. uses Maze_factory Client uses Make_maze()Make_room() Make_wall() Make_door() Room uses Room_with_bomb Enchanted_room Enchanted_factory Bombed_factory create Make_wall() Make_room() Make_room()Make_door() uses Wall Door Bombed_wall Door_need_spell create Lopputulos: Abstract Factory

33. uses AbstractFactory Client uses createProductA()createProductB() AbstractProductA ProductA2 ProductA1 ConcreteFactory2 ConcreteFactory1 create uses createProductA()createProductB() createProductA()createProductB() AbstractProductB ProductB2 ProductB1 create Abstract Factory Pattern

34. Singleton Pattern • Konteksti: • On hyvin tavallista että tietystä luokasta pitäisi olla olemassa vain yksi instanssi (singleton) • Ongelma: • Kuinka varmistat, että luokkaa ei missään tilanteessa luoda enemää kuin yksi olio? • Vahingoittavia voimia: • public konstruktorin käyttö ei takaa, että olioita tulee vain yksi. • singleton instanssi pitää olla kaikkien halukkaiden luokkien käytettävissä

35. Singleton Pattern class Singleton {public:static Singleton *get_instance();protected: Singleton(); Singleton( const Singleton& s);private:static Singleton *instance;};Singleton::instance = 0; Singleton *Singleton::get_instance() {if ( instance == 0 ) { instance = new Singleton; }return instance;} «Singleton» theInstance getInstance Company theCompany Company «private» getInstance if (theCompany==null) theCompany= new Company(); return theCompany;

36. Esimerkki: Singleton patternin käyttö labyrintissä Class Maze_factory { public: static Maze_factory* get_instance(); //existing interface goes here… protected: Maze_factory(); Maze_factory(const Maze_factory& f); private: static Maze_factory* instance; }; Maze_factory::instance = 0; Maze_factory* Maze_factory::get_instance(){ if (_instance == 0) _instance = new Maze_factory; return _instance; }

37. Missä mennään? • Design Patterneista Yleisesti • Historiatietoa • Määrittely • Ominaisuuksia • Design Patternien kuvaustavat • Patterntyypit • Patternkieli, systeemi, kataloogi • Design patternien käyttö oliopohjaisen järjestelmän kehityksessä • AntiPattern • Esimerkkejä Design Patterneista • Creational Patterns • Structural Patterns • Behavioral Patterns

38. Adapter Pattern • Konteksti • Olet rakentamassa perintähierarkiaa ja haluat käyttää siinä hyväksi jo olemassa olevaa luokkaa • Uudelleenkäytetty luokka on usein jo osa omaa perintähierarkiaa • Ongelma • Kuinka voi käyttää polymorphismin etuja hyväksi kun uudelleenkäyttää olemassa olevan luokan metodeja, jotka: • sisältävät halutun toiminnallisuuden • mutta funktion nimikirjoitus (signature) ei ole sama kuin muut hierarkiassa olevat metodit? • Vahingoittavat voimat • Et halua tai saa käyttää moniperintää.

39. polymorphicMethod() { return «Superclass» adaptee.adaptedMethod(); polymorphicMethod } «Adapter» «Adaptee» adaptedMethod Adapter

40. Façade Pattern • Konteksti • Sovellus sisältää usein useita monimutkaisia moduuleja • Ohjelmoijan, joka käyttää moduuleja täytyy manipuloida useita eri luokkia • Ongelma • Kuinka voi yksinkertaistaa monimutkaisten moduulien käytettävyyttä? • Vahingoittavat voimat • Ohjelmoijan on vaikea ymmärtää ja käyttää kokonaisia alisysteemejä • Jos useat eri sovelluksen luokista kutsuvat moduulin metodeita, niin moduulin kohdistuvat muutokset pakottaa katselmoimaan uusiksi kaikki ne luokat jotka pakettia käyttävät.

41. Façade

42. Proxy • Konteksti • On usein aikaavievää ja monimutkaista luoda raskaasta luokasta (heavyweight class) olioita • Tällaisen olion luomiseen liittyy monimutkainen luontimekanismi ja se aiheuttaa aikaviiveen • Ongelma • Kuinka voisi vähentää tarvetta luoda instansseja raskaista luokista? • Vahingoittavat voimat • Kaikki oliot on oltava käytettävissä tarpeen mukaan • Joillekin olioille on tärkeää olla olemassa koko ohjelman ajon ajan

43. Proxy Käyttötarkoituksia: • Remote Proxy voi piilottaa tiedon siitä, että todellinen olio onkin toisessa muistiavaruudessa object is in another address space. • Virtuaali Proxyt voi luoda resursseja syövät oliot tarpeen vaatiessa. • Protection proxy voi kontrolloida käyttöoikeuksia olioon.

44. Missä mennään? • Design Patterneista Yleisesti • Historiatietoa • Määrittely • Ominaisuuksia • Design Patternien kuvaustavat • Patterntyypit • Patternkieli, systeemi, kataloogi • Design patternien käyttö oliopohjaisen järjestelmän kehityksessä • AntiPattern • Esimerkkejä Design Patterneista • Creational Patterns • Structural Patterns • Behavioral Patterns

45. Chain of Responsibility Tarkoitus: • Välttää pyynnön lähettäjän ja vastaanottajan kytkemistä (coupling) tarjoamalla useita vaihtoehtoisia olioita, jotka voivat hoitaa pyynnön. Pyynnön vastaanottajaoliot (handler) ketjutetaan ja pyyntöä kuljetetaan handlerilta toiselle kunnes jokin handlereista hoitaa sen. Esimerkki: • Käyttöliittymän context-sensitive help ominaisuus. Käyttäjä voi saada apua mistä tahasa käyttöliittymän osiosta klikkaamalla kyseistä käyttöliittymän osaa. Jos tästä osasta ei ole ohjeita saatavilla, yleisempi ohje valitusta kontekstista esitetään.

46. Observer Tarkoitus: • Määrittelee one-to-many riippuvuuden olioiden välille siten, että kun yksi olio muuttaa tilaansa kaikki siitä riippuvat oliot päivittyvät. Muuttoksen aiheuttava olio ei välttämättä tiedä muita muutettavia olioita

47. * * * * * * * «interface» Observable Observer Observers are notified when a new prediction is ready Forecaster WeatherViewer Observer -Esimerkkejä

48. Iterator Tarjoaa keinon päästä käsiksi aggregaatin hallinoimiin elementteihin ilman, että aggregaatin sisäinen toteutus paljastuu Tarjoaa yhtenäinen rajapinta eri aggregaatti rakenteiden selailuun esimerkki: Standard Template Library (STL) container iteraattorit.