2015 syksy 2. vsk VI Johdanto suunnittelumalleihin
Sisältö 1. Taustaa 2. Model View - Controller 3. Suunnittelumallin kuvaamisesta 4. Tavoitteita 5. Suunnitteluongelmien suhde malleihin 6. Suunnittelumallien luokittelua 7. Suunnittelumallin valinta ja käyttö Suunnittelumallit johdanto 2
VI.1 Taustaa Ekspertit tyypillisesti uudelleenkäyttävät ratkaisuja, jotka ovat olleet toimivia Monissa oliopohjaisissa sovelluksissa tietyt rakenteet toistuvat Kaavamainen tapa ratkaista tietty osaongelma Tavoitteena ratkaisun uudelleenkäyttö sekä joustavuus Suunnittelumallit johdanto 3
VI.1.1 Historiaa 1970-luvulla Alexander: Mallikieli arkkitehtuuriin ja yhdyskuntasuunnitteluun Arkkitehtien väliseen kommunikointiin 1980-luvulla Smalltalk Käyttöliittymässä MVC-malli, sisältää tunnistettavia olio-ohjelmoinnin suunnittelumalleja 1990-luku: Suunnittelumallien muodollinen kuvaaminen Suosituksi olio-ohjelmoinnissa Gamma, Helm, Johnson, Vlissides ( Gang of Four, GoF): Design patterns: Elements of Reusable Software (1995) Suunnittelumallit johdanto 4
VI.1.2 Terminologiaa Idiomi (Idiom) Tietyn asian rutiininomainen ratkaisu. Esim. taulukon läpikäynti Yleensä kieliriippuvainen Yksittäinen ratkaisu (Specific design) Jonkin tietyn ongelman ratkaisu Standardimainen ratkaisu (Standard design) Tietyntyyppisen ongelman ratkaisu Suunnittelumalli (Design pattern) Yleispätevä ratkaisu joukkoon tietyntyyppisiä ongelmia. Usein yleistetty standardimainen ratkaisu Suunnittelumallit johdanto 5
VI.1.3 Suunnittelumallin laajuus Yleensä suunnittelumalli käsittää muutaman luokan ja niiden väliset suhteet Malli kuvaa yleisen rakenteen osasta järjestelmää Samaa suunnittelumallia voidaan soveltaa useilla eri abstraktiotasoilla Joukko toisiinsa liittyviä suunnittelumalleja muodostaa mallikokoelman (pattern catalog) Julkinen tai organisaation sisäinen Mallikieli (pattern language) on kyseessä silloin, kun mallien väliset suhteet on eksplisiittisesti kuvattu Suunnittelumallit johdanto 6
VI.1.4 Mallin perusominaisuudet Nimi Oltava kuvaava, lisää sanastoa Malliin liittyvä ongelma Tilanteita, joihin mallia voi soveltaa Suunnitteluongelmia tai hankalia luokkarakenteita Ratkaisu Olennaiset osat, niiden suhteet ja yhteistoiminta Abstrakti kuvaus Seuraukset Mihin ratkaisun soveltaminen johtaa Minkälaisia kompromisseja aiheuttaa Suunnittelumallit johdanto 7
VI.2 Model View Controller Otettiin käyttöön 1980-luvulla Smalltalkissa Käyttöliittymän rakentamisessa Model: sovellusolio, sisältää datan, tietomalli View: näkymä Yhtä mallia voi vastata useita näkymiä Rekisteröityvät tietyn mallin tarkkailijoiksi Controller: miten käyttöliittymä reagoi käyttäjän syötteisiin Malli muuttuu -> Controller ilmoittaa mallin tarkkailijoille -> Päivittävät itsensä Suunnittelumallit johdanto 8
VI.2.1 Suunnittelumalleja MVC:ssä MVC:ssä näkymät limittyvät -> Composite (Kooste)- suunnittelumalli Toiminta yleistetään ->Observer (Tarkkailija)- suunnittelumalli Lähde: Gamma, Helm, Johnson, Vlissides: Design Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley 1995 Suunnittelumallit johdanto 9
VI.3 Suunnittelumallin kuvaamisesta Yleensä luonnollisella kielellä Täydennetään UML-kaavioilla ja esimerkkikoodilla GoF: mallin rakenne (tärkeimmät): 1. Mallin nimi ja luokittelu (Name and Classification) Sopiva nimi helpottaa kommunikointia 2. Tarkoitus (Intent) Toiminta, minkälaisiin ongelmiin soveltuu 3. Perustelut (Motivation) Miten luokkien ja olioiden rakenne ratkaisee suunnitteluongelman Suunnittelumallit johdanto 10
VI.3 Suunnittelumallin kuvaamisesta (2) 4. Soveltuvuus (Applicability) Tilanteita, joihin mallia voidaan soveltaa 5. Rakenne (Structure) Luokkakaavio, oliokaavio, vuorovaikutuskaavioita 6. Osallistujat Luokat ja oliot sekä niiden vastuut 7. Seuraukset Mihin mallin soveltamisella sitoudutaan 8. Toteutus Vihjeitä implementointiin Suunnittelumallit johdanto 11
VI.4 Tavoitteita Mallien luokittelulla ja nimeämisellä yhtenäinen sanasto Ongelman käsittely korkeammalla abstraktiotasolla Mallien tunteminen auttaa ymmärtämään ohjelmakoodia paremmin Ainakin, jos dokumentoinnista selviää, mitä mallia on käytetty Mallit hyödyntävät kokeneiden suunnittelijoiden tietoja Suunnittelumallit johdanto 12
VI.5 Suunnitteluongelmien suhde malleihin Joskus toteutettava monimutkaisia toimintoja Joidenkin suunnittelumallien avulla sopiva rakenne, esim. Strategy (Strategia) Joskus tarvitaan valtava määrä olioita Hallitsemiseen malleja, esim. Flyweight (Hiutale) ja Facade (Julkisivu) Joskus luotava olio, jonka tyyppi ei selvillä käännöksen aikana Builder (Rakentaja), Abstract Factory (Abstrakti tehdas) Luokkahierarkian olioiden selaaminen hankalaa Visitor (Vierailija), Command (Komento) Suunnittelumallit johdanto 13
VI.5 Suunnitteluongelmien suhde malleihin Halutaan poistaa riippuvuus tietyistä operaatioista ja algoritmeista Suunnittelumalleja näiden eristämiseen (esim. Template Method [Operaatiorunko]) Olioiden ja luokkien väliset riippuvuuksien poistaminen Malleilla voidaan löyhentää, esim. Observer Valmis luokka ei sovi uuteen rajapintaan Adapter-malli (Sovitin) Suunnittelumallit johdanto 14
VI.6 Suunnittelumallien luokittelu Kaksi ulottuvuutta: 1. Mallin tarkoitus Olioiden luominen Rakenteellinen Käyttäytyminen 2. Mallin kohde Luokkamalli Luokkarakenne käännösaikainen -> staattinen Oliomalli Oliot ajonaikaisia -> dynaaminen Suunnittelumallit johdanto 15
IV.6 Suunnittelumallien luokittelu (2) GoFin mallien luokittelu Lähde: Lasse Harjumaan luentokalvot Suunnittelumallit johdanto 16
IV.6.1 GoF, luontimallit Abstract Factory Provide an interface for creating families of related or dependent objects without specifying their concrete classes. Builder Separate the construction of a complex object from its representation so that the same construction process can create different representations. Factory Method Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses. Prototype Specify the kinds of objects to create using a prototypical instance, and create new objects by copying this prototype. Singleton Ensure a class only has one instance, and provide a global point of access to it. Suunnittelumallit johdanto 17
VI.6.2 GoF, rakennemallit Adapter Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn't otherwise because of incompatible interfaces. Bridge Decouple an abstraction from its implementation so that the two can vary independently. Composite Compose objects into tree structures to represent partwhole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly. Decorator Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality. Facade Provide a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use. Flyweight Use sharing to support large numbers of fine-grained objects efficiently. Proxy Provide a surrogate or placeholder for another object to control access to it. Suunnittelumallit johdanto 18
VI.6.3 GoF, käyttäytymismallit Chain of Responsibility Avoid coupling the sender of a request to its receiver by giving more than one object a chance to handle the request. Chain the receiving objects and pass the request along the chain until an object handles it. Command Encapsulate a request as an object, thereby letting you parameterize clients with different requests, queue or log requests, and support undoable operations. Interpreter Given a language, define a represention for its grammar along with an interpreter that uses the representation to interpret sentences in the language. Iterator Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation. Mediator Define an object that encapsulates how a set of objects interact. Mediator promotes loose coupling by keeping objects from referring to each other explicitly, and it lets you vary their interaction independently. Suunnittelumallit johdanto 19
VI.6.4 GoF, käyttäytymismallit (2) Memento Without violating encapsulation, capture and externalize an object's internal state so that the object can be restored to this state later. Observer Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically. State Allow an object to alter its behavior when its internal state changes. The object will appear to change its class. Strategy Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it. Suunnittelumallit johdanto 20
VI.6.4 GoF, käyttäytymismallit (3) Template Method Define the skeleton of an algorithm in an operation, deferring some steps to subclasses. Template Method lets subclasses redefine certain steps of an algorithm without changing the algorithm's structure. Visitor Represent an operation to be performed on the elements of an object structure. Visitor lets you define a new operation without changing the classes of the elements on which it operates. Suunnittelumallit johdanto 21
IV.7 Suunnittelumallin valinta ja käyttö GoF: Suositus mallin käyttöön: 1. Varmista, että käytät oikeaa mallia Tarkista sovellettavuus ja seuraukset 2. Varmista, että ymmärrät mallin rakenteen ja käyttäytymisen Rakenne, osallistujat, yhteistyösuhteet 3. Tutustu esimerkkikoodiin Suunnittelumallit johdanto 22
IV.7 Suunnittelumallin valinta ja käyttö (2) 4. Määrittele osallistuvien luokkien nimet. Kuvauksessa olevat nimet ovat liian geneerisiä, lisäksi malli yleensä upotetaan toteutukseen 5. Määrittele tarvittavat luokat Muokattavat ja uudet 6. Määrittele operaatiot ja niiden nimet 7. Toteuta operaatiot Suunnittelumallit johdanto 23