5. Suunnittelumallit. TTY Ohjelmistotekniikka

Transkriptio

1 5. Suunnittelumallit Suunnittelumallin käsite Suunnittelumallien hyötyjä Suunnittelumallien kuvaaminen Antisuunnittelumallit Esimerkki: Rekursiokooste Suunnittelumallit ja kehykset Suunnittelumallit ja UML Suunnittelumallit eivät ole... Yhteenveto 1

2 Suunnittelumallin käsitek Cristopher Alexander et al.: A Pattern Language, 1977 Cristopher Alexander: The Timeless Way of Building, 1979 Maailma koostuu toistuvista tiettyjen mallien ilmentymistä Esimerkki: Jokainen maanviljelijä osaa rakentaa ladon - miksi? Malli (pattern) on yleistä suunnitteluosaamista, joka olisi saatettava kaikkien tarvitsijoiden ulottuville Paljon käytetty insinöörialoilla Erityisen hyödyllinen ajatus ohjelmistotekniikassa 2

3 Esimerkki: Ikkunat ja ovet hirsitalossa hirret painuvat kasaan Ongelma: ikkunat ja ovet ovat kiinteitä, vaikka hirsiseinä liikkuu ja painuu kasaan. Ratkaisu: ikkunoiden ja ovien karmeja ei kiinnitetä suoraan seinään, vaan "karaan", joka liikkuu vapaasti hirsiin tehdyssä urassa. 3

4 Mikä on suunnittelumalli? Suunnittelumalli Yleinen ratkaisu usein esiintyvään arkkitehtuuritai suunnitteluongelmaan tietyssä yhteydessä. 4

5 Selitystä Yleinen ratkaisu... ei liity tiettyyn kieleen tai teknologiaan,. kuvataan yleisellä tavalla... usein esiintyvään... täytyy olla useita soveltamiskohteita (esim. GoF: 3)... arkkitehtuuri- tai suunnitteluongelmaan... sovelletaan ohjelmistotekniikassa arkkitehtuurin ja yksityiskohtaisen suunnittelun tasolla... tietyssä yhteydessä. ongelma esiintyy yhteydessä, josta seuraa erilaisia vaatimuksia ja voimia 5

6 Suunnittelumallien hyötyj tyjä Suunnittelumallit... tuovat piilossa olevan suunnittelutietämyksen kaikkien saataville; auttavat järjestelmän dokumentoinnissa; antavat uuden korkeamman tason toteutusvälineen; toimivat arkkitehtuurin rakennuspalikoina; antavat suunnittelijoille yhteisen sanaston. 6

7 Suunnittelumallin kuvaus Keskeiset osat: Nimi Ongelma Ratkaisu Seuraukset Toteutus Kuvaava ytimekäs nimi, tulee osaksi yhteistä sanastoa Ongelman ja siihen vaikuttavien tekijöiden kuvaus, oletukset, esimerkki Luokkien ja olioiden organisointi ongelman ratkaisemiseksi (esim. käyttäen UML:ää) Ratkaisun edut ja haitat Erilaiset toteutustavat, toteutus eri kielillä ym. toteutukseen liittyvät näkökulmat 7

8 "Gang of Four kirja, GoF: GoF:in kuvausformaatti Gamma E., Helm R., Johnson R., Vlissides J.: Design Patterns - Elements of Reusable Object-Oriented Software. Addison-Wesley Name (and category) Intent Also known as Motivation Applicability Structure Participants Collaborations Consequences Implementation Sample code Known uses Related patterns 8

9 Antisuunnittelumallit Ongelma Suunnittelumalli Hyvä ratkaisu Seuraukset Antisuunnittelumalli Huono ratkaisu Oireet Muokkaus Antisuunnittelumalli = huono ratkaisu + hyvä ratkaisu Suunnittelumalli = ongelma + ratkaisu Brown W.J. et al.: Antipatterns - Refactoring Software, Architectures, and Projects in Crisis. Wiley

10 Dokumentoituja antisuunnittelumalleja The Blob Lava flow Golden Hammer Spaghetti Code Cut-and-Paste Programming 10

11 Antisuunnittelumallien oireita Huono ylläpidettävyys Huono uudelleenkäytettävyys Huono laajennettavuus Vaikeasti ymmärrettävä Tehottomuus 11

12 Vihjeitä antisuunnittelumallien käytk ytöstä Koodin toistoa Mahdolliset vaihtoehdot jollekin asialle kiinnitetään staattisesti koodissa Suuria luokkia ja operaatioita 12

13 Mitä huonoja ratkaisutapoja olet tunnistanut oliojärjestelmiss rjestelmissä? 13

14 Esimerkki: Rekursiokooste Ongelma: kuinka hallita hierarkkisesti järjestettyä oliokokoelmaa niin, että kokoelman käyttäjän ei tarvitse tuntea rakenteen organisointitapaa? Käyttäjä tee joku operaatio lehtiolioille 14

15 Suunnittelumallin kehittäminen (1) Ensimmäinen ratkaisu: kaksi tasoa Composite forall() * children Leaf operation() if X is Composite then X.forall() else X.operation;... For all children c: c.operation() Seuraukset: - Koosteoliot ja lehtioliot käsitellään eri tavalla koodissa - Vaikea laajentaa ratkaisua uusille kooste- ja lehtioliotyypeille - Sallii vain kaksi tasoa if X is Composite then Op1(, X, ) else Op2(, X, );... 15

16 Suunnittelumallin kehittäminen (2) Toinen ratkaisu: Yhdistetään kooste- ja lehtiolioluokat * children Item operation() íf I have children then for all children c: c.operation() else dosomething(); Seuraukset: - Kooste- ja lehtioliot käsitellään samalla tavalla - Rajoittamaton hierarkia - Vain yhden tyyppisiä olioita -> koodiin tulee tyyppihaarautumisia Client: item.operation() 16

17 Suunnittelumallin kehittäminen (3) Kolmas ratkaisu: Eri tyyppisiä olioita Seuraukset: - Kuten edellä, paitsi että erityyppiset oliot eivät aiheuta haarautumisia koodissa (dosomething1&2) - Silti, yksi tyyppipohjainen haarautuminen jää: kooste vs. lehti * Item children operation() íf I have children then for all children c: c.operation() else dosomething1() Item1 operation() Item2 operation() íf I have children then for all children c: c.operation() else dosomething2() 17

18 Suunnittelumallin kehittäminen (4) Neljäs ratkaisu: Erotetaan kooste- ja lehtiluokat * children Item operation() Item1 Composite dosomething operation() operation() for all children c: c.operation() 18

19 Rekursiokooste suunnittelumalli Nimi: Rekursiokooste Ongelma: Kuinka hallita hierarkkisesti järjestettyä oliokokoelmaa niin, että kokoelman käyttäjän ei tarvitse tuntea rakenteen organisointitapaa?? Ratkaisu: Item operation() * children Leaf operation() Composite operation() For all children c: c.operation() 19

20 Rekursiokooste (jatkuu) Soveltuu, kun: haluat esittää hierarkkisesti järjestettyjä oliokokoelmia, haluat että oliokokoelman käyttäjät eivät tule riippuvaiseksi kokoelman organsiointitavasta. Seuraukset: Kooste- ja lehtiolion ero ei näy käyttäjän koodissa Käyttäjän koodi yksinkertaistuu Rakenteeseen on helppo lisätä uusia kooste- ja lehtiluokkia (ei näy käyttäjälle) Pieni tehokkuusrasite kutsun siirtämisen takia 20

21 Rekursiokooste (jatkuu) Toteutusnäkökohtia Tarvitaanko linkit lehti kooste molempiin suuntiin? Voiko samalla oliolla olla useita kooste-vanhempia? Yhteinen rajapinta vs. tyyppiturvallisuus? Onko lapsiolioilla järjestys? Kuka luo ja hävittää rakenteen? 21

22 Esimerkki soveltamisesta SourceManager Source delete() print() * children File delete() print() Folder delete() print() add(source) For all children c: c.delete(); Delete folder 22

23 Esimerkki soveltamisesta Graphicaltem draw * children Rectangle Circle FigGroup draw draw draw for all children c: c.draw; 23

24 Suunnittelumallit ja kehykset Graphicaltem draw * children Kehys Rectangle Circle FigGroup draw draw draw Sovellus for all children c: c.draw; 24

25 Suunnittelumalli ja sen ilmentymä Suunnittelumallin louhinta Suunnittelumalliluettelo Suunnittelumalli Osittainen suunnittelumallin ilmentymä Kehys Suunnittelumallin ilmentymä Sovellus Suunnittelumallin toteutus 25

26 Suunnittelumallit ja UML Composite Item Statement * execute() Leaf Composite SimpleStatement execute() Block execute() children 26

27 Suunnittelumallit ja UML EventSource register(statemachine) * * informs StateMachine 1 run(state) handle(event) Singleton State Observer Event source(): Object current.exit(); current = current.transit(e); current.entry(); uses 0..1 current State transit(event): State entry() exit() Event1 source(): Object Event2 source(): Object StateA transit(event): State entry() exit() StateB transit(event): State entry() exit() 27

28 Stereotyyppien käyttk yttö <<Composite:item>> Statement * execute() <<Composite:leaf>> SimpleStatement execute() <<Composite: composite>> Block execute() children 28

29 Suunnittelumallit eivät t ole yleinen lääke ohjelmiston laadun parantamiseen; ongelmattomia: arkkitehtuurin monimutkaistuminen mahdollinen ongelman yliratkaisu (overkill) tehokkuus: runsaasti dynaamista sidontaa olion identiteetti hämärtyy: olioskitsofrenia tarvitsevat hyvän dokumentoinnin järjestelmässä 29

30 Yhteenvetoa Suunnittelumallit antavat hyväksi havaittuja ratkaisuja yleisiin suunnitteluongelmiin Suunnittelumallit ovat kehysten rakenneosia Käytä suunnittelumallia vasta kun ongelma on selvästi ymmärretty Suunnittelumallit ovat kokemusperäistä tietoa, eivät innovaatioita 30