Suunnittelumalli

Suunnittelumallin nimi kuvaa mallin sisältämän periaatteen lyhyesti ja yksiselitteisesti. Mallin nimen perusteella voidaan nopeasti hahmottaa käytetty rakenne, sen tuottama hyöty ja siihen liittyvät rajoitukset. Mallin nimi auttaa ohjelmiston suunnittelemaan ajattelemaan ohjelmistorakennetta yleisellä (abstraktilla) tasolla, ja sen käyttö voi helpottaa suunnittelijoiden välistä keskustelua.[12] Suunnittelumallin nimen tulisi olla osa suunnittelijan ammattisanastoa, mutta tilannetta on vaikeuttanut mm. se, että sama suunnittelumalli on nimetty eri nimillä tai käytännössä samat suunnittelumallit on nimetty eri nimillä. Samaa nimeä voidaan myös käyttää eri suunnittelumalleille.[13]

Ongelma (Problem) kuvaa ohjelmoinnissa esiintyvää tavanomaista tilannetta, jonka ratkaisemisessa suunnittelumalli on ollut hyödyksi. Ongelman kuvaus voi olla laaja arkkitehtuuriin liittyvä tai sitten suppeampi, esim. tietyn algoritmin kuvaus. Suunnittelumalli voi joskus sisältää ominaisuuksia, joiden vuoksi sitä ei ole tarkoituksenmukaista käyttää muissa kuin erityistilanteissa. Nämä erityistilanteet on kuvattu tässä osassa suunnittelumallin määrittelyä.[14] Ongelman tulee ilmetä toistuvasti monenlaisissa ohjelmistoissa ja sen tulee olla yleisluontoinen (esim. ohjelmointikielestä riippumaton). Muut kuin arkkitehtuuri- tai yksityiskohtaiseen suunnitteluun liittyvät ongelmat rajataan pois.[15]

Ongelma esittää tilanteen, jossa mallia voidaan soveltaa. Ongelman kuvaus esitetään tarkasti identifioituna, mikä helpottaa käyttöalueen määritystä. Kuvaus voi myös esittää jonkin tyypillisen joustamattoman rakenteen, jota on parannettava. Suunnittelumallia ei ole syytä käyttää ellei ongelman kuvaus vastaa toteutettavassa ohjelmistossa esiintyvää ongelmatilannetta. Yleisesti voidaan todeta, että suunnittelumallien tehokas soveltaminen vaatii huolellista pohdintaa, sillä mallien soveltaminen voidaan tehdä vain suppeasti määritellyllä ongelma-alueella. Joskus ongelman kuvaus sisältääkin listan ehdoista joiden tulee täyttyä ennen kuin on hyödyllistä soveltaa suunnittelumallia.

Ongelmayhteys (Context) kuvaa sen kokonaisuuden, jossa ongelma ilmenee, ja se kertoo sen, missä tilanteissa suunnittelumallia voidaan käyttää. Ongelmayhteys määrittää lisäksi ratkaisulle asetettavia vaatimuksia ja niitä ohjelman laatuominaisuuksia, joita ratkaisun tulisi parantaa. Usein ongelma ja ongelmayhteys esitetään yhdessä, ja niitä havainnollistetaan esimerkeillä.[16]

Ratkaisu (Solution) kuvaa mahdollisen ohjelmointirakenteen ja sen osat (esim. luokat, oliot, algoritmit), osien väliset suhteet ja niiden välisen vuorovaikutuksen (yleensä funktiokutsut) yleisellä tasolla. Ratkaisun antamia ohjelmoinnin suuntaviivoja on käytettävä käsitteellisenä runkona laadittaessa käytännön ratkaisua käsillä olevaan ohjelmointiongelmaan. Ohjelmistosuunnittelija arvioi tapauskohtaisesti sen, miten mallin ratkaisu sopii kyseessä olevaan tilanteeseen.[14] Ratkaisun tulee olla sovellettavissa yleisesti ohjelmoinnissa, ja se tulee pystyä esittämään yleisti käytössä olevalla mallinnuskielellä (esim. UML). Ratkaisun yleiskäyttöisyydestä voi seurata se, että ohjelmiston laatuominaisuudet (esim. nopeus) heikkenee.[15]

Ratkaisu on suunnittelumallin tärkein asia, ja se esitetään usein staattisena rakenteena (esim. UML:n luokkakaavio) jota täydennetään dynaamisen vuorovaikutuksen kaaviolla (esim. UML:n sekvenssikaavio). Kuvausta voidaan täydentää pseudokoodikuvauksella, joka kuvaa ohjelman kulun vaihe vaiheelta.[15]

Ratkaisun tehtävänä on muodostaa yleinen kuvaus ongelman ratkaisusta. Ratkaisu kuvaa toteutuksessa käytettävät luokat, rajapinnat ja oliot, sekä niiden suhteet yleisellä tasolla. Vaikka ratkaisun rakenne esitetään yleensä UML-kaaviolla tai jollain muulla oliorakennetta kuvaavalla yleisesti tunnetulla kuvaustavalla (notaatio), ei ratkaisu kuvaa mitään erityistä tilannetta vaan yleisen tavan ratkaisulle. Tosin yksinkertainen esimerkki helpottaa ratkaisun toteutustavan ymmärtämistä. Ratkaisussa ei yleensä oteta kantaa käytettävään ohjelmointikieleen, mutta esimerkiksi moniperinnän puuttuminen osasta oliokieliä saattaa hankaloittaa ratkaisun toteuttamista. Yleisesti suunnittelumalleissa ei käytetä jonkin tietyn kielen erityisominaisuuksia ongelman ratkaisuun.

Seuraukset kuvaa mallin vaikutusta ohjelman sisäiseen ja ulkoiseen toimintaan, sekä sen käytöstä seuraavia hyviä ja huonoja seikkoja. Ohjelmistojen toiminnan kannalta tärkeitä seurauksia ovat mm. muisti ja suoritusaika ja ohjelmiston uudelleenkäyttö. Ohjelmiston uudelleenkäytön kannalta tärkeitä seurauksia ovat mm. käytetyn mallin vaikutus ohjelman laajennettavuuteen, muunneltavuuteen ja siirrettävyyteen.[12] Mikään suunnittelumalli ei tuota joka suhteessa parasta ratkaisua, vaan kukin niistä optimoi tietyt ohjelman laatuominaisuudet ja heikentää muita. Seurausten kuvaaminen auttaa suunnittelijaa arvioimaan sitä, miten malli soveltuu käsillä olevaan suunnittelutilanteeseen. Seurauksista kertominen helpottaa suunnittelumallin soveltamista käytännön ohjelmistotyössä.[15]

Toteutusnäkökulma kertoo käytännön ohjelmoinnissa esiintyvien tilanteiden ratkaisemisesta, esimerkiksi kertomalla mallin käytöstä eri ohjelmointikieliä käytettäessä. Toteutusnäkökulma on pidettävä erillään suunnittelumallin esittämästä teoreettisesta ajattelutavasta. Suunnittelumallin käytöstä voidaan antaa esimerkki todellisen järjestelmän toteutuksessa tai ohjelmointikielikohtaisena.[17]

Luontimalli on suunnittelumalli, jolla ohjelmassa toimivan olion rakentaminen esitetään käsitteellisellä tasolla. Luontimalli peittää konkreettisesti käytettävien tuotantoluokkien näkyvyyden niitä käyttäviltä luokilta ja sen, miten tuotantoluokkia luodaan ja yhdistellään toisiinsa, eli tuotantoluokkia käyttävä tilaajaohjelma tuntee niistä vain niiden abstraktissa luokassa esitettävän rajapinnan. Rajapinnan käyttö mahdollistaa sen, että tuotantoluokkia ja niiden välisiä suhteita on helppo muuttaa ilman että sillä olisi vaikutusta luokkia tilaavan ohjelman toimintaan.[19] Luontimalli kuvaa olioiden luomisprosessin, eli sen, kuinka, koska ja mitä olioita luodaan, ja huolehtivat luokkien ja olioiden asetusten konfiguroinnista[20].

Luontimalli on suunnittelumalli, jossa monimutkainen toiminnallisuus toteutetaan yhdistämällä useita eri toiminnallisuuksia. Luontimallit kätkevät tiedon siitä, mitä luokkia toiminnallisuuden toteuttamisessa käytetään ja miten näitä luokkia käytetään, luodaan ja liitetään toisiinsa.[19]

Epäkonkreettinen tehdas (Absract Factory, Kit) on olion luontimalli, jossa konkreettisten luokkien olioryhmä (-perhe) luodaan luokasta jolla itsellään ei ole konkreettista ilmentymää (abstrakti luokka). EKT on rajapintaluokka, joka yhdistää toisiinsa saman tyyppisiä oliota.[21]

EKT:tä voidaan käyttää ohjelman rakenteen mallina esim. käyttöliittymän toteutukseen eri alustoilla seuraavasti: Sovellusta käytetään eri käyttöliittymässä, jolloin käyttöliittymän rakentamistyökalun tulee tukea erilaisia käyttöliittymästandardeja. Käyttöliittymää luotaessa sovellus kutsuu abstraktin luokan (esim. UITehdas) funktiota (esim. luoIkkuna(), luoVierityspalkki(), luoPainonappi), joka edelleen kutsuu kyseisen ohjelmaympäristön konkreettista luokkaa, joka toteuttaa tarvittavat toiminnallisuudet.[21]

EKT toteutetaan usein tehdasmenetelmällä, ja toteutuksessa voidaan käyttää myös prototyyppimallia. Abstraktin tehtaan alaluokka konkreettinen tehdas on tavallisesti ainokainen (luokasta luodaan vain yksi ilmentymä).[22]

Rakentajarajapinta (Builder) on olion luontimalli, jossa erotetaan toisistaan olion esitysmuoto ja sen luomisprosessi. Tämän vuoksi sama prosessi voi tuottaa erilaisia olioita. Abstrakti rakentaja on abstrakti rajapintaluokka, joka luo konkreettisen rakentajaluokan osat. Rakentajaluokka toteuttaa halutut toiminnallisuudet (tuotteet).[23]

Rakentajaa voidaan käyttää ohjelman rakenteen mallina esim. muunnettaessa RTF-muotoista tekstiä muihin tekstiformaatteihin (esim. ASCII, muotoiltu teksti, jota ei voida muokata, muotoiltu teksti, jota voidaan muokata). RTFLukija (pääohjelma) kutsuu abstraktin rakentajan (TekstiKonvertoija), joka kutsuu edelleen konkreettisen rakentajan (ASCIIKonvertoija, TekstiKonvertoija, TekstiMuokkausKonvertoija) pääohjelman funktiokutsun sisältämän tiedon mukaan. Konkreettinen rakentaja määrittelee tuotteen kokoamisen prosessin ja kokoaa tuotteen sisäisen esitysmuodon.[23]

Rakentajarajapinta muistuttaa epäkonkreettista tehdasta siinä, että molemmilla voidaan toteuttaa monimutkaisia toiminnallisuuksia. Mallit eroavat toisistaan siinä, että epäkonkreettinen tehdas palauttaa pyydetyn tuotteen välittömästi, kun taas rakentajarajapinta valmistaa tuotteen vaiheittain ja palauttaa sen prosessin viimeisenä vaiheena. Rakentajarajapintaa käytetään usein rekursiokoosteen kokoamiseen.[24]

Tehdasfunktio (Factory Method, Virtual Constructor) on luokan luontimalli, jossa käytetään abstraktia funktiokutsua. Olion kutsumuoto on määritelty, ja luokan ilmentymän luominen on aliluokan tehtävä. Tehdasfunktiomallissa abstrakti luokka kapseloi konkreettisen luokan tarvitsemat tiedot ja välittää ne konkreettiselle tuotantoluokalle.[25] Tehdasfunktiota voidaan käyttää ohjelman rakenteen mallina esim. sovelluksessa, joka tuo käyttäjän muokattavaksi useita dokumentteja.[26]

Prototyyppirajapinta (Prototype) on olion luontimalli, jossa olion määrittely suoritetaan abstraktilla prototyyppiluokalla. Olio luodaan prototyyppiluokkaa kutsumalla ja luomalla siitä kopioita (kloonaus). Kopioiden ominaisuuksia voidaan muokata parametreilla, jolloin voidaan vähentää luokkien määrää.[27]

Ainokainen (Singleton) on olion luontimalli, jossa luokasta luodaan täsmälleen yksi konkreettinen ilmentymä. Ilmentymään pääsy on globaali.[28]

Rakennemalli on suunnittelumalli, joka kuvaa luokkia (ja olioita) ja niiden yhdistelyä suuremmiksi rakenteiksi[29]. Rakennemalli kuvaa tavan, jolla luokkia ja olioita käytetään laajoissa rakenteissa. Rakennemalli esittää rajapinnat ja toteutuksen toisistaan erotettuina.[7]

Sovitin (Adapter, Wrapper) on luokan tai olion rakennemalli, jossa kaksi toisiinsa sopimatonta rajapintaa liitetään toisiinsa käyttäen rajapintaluokkaa.[30]

Silta (Bridge, Handle, Body) on ohjelmiston rakennemalli, jossa sovellukseen liitetty abstrakti rajapintaluokka kutsuu haluamansa toiminnallisuuden abstraktilta toiminnallisuuden rajapintaluokalta. Nämä kaksi rajapintaa muodostavat sillan, ja molempia rajapintoja voidaan vapaasti muunnella.[31]

Koosteensa sisältävä kooste (rekursiokooste, Composite) on ohjelmiston rakennemalli, jossa yksi koosteolion rakentava abstrakti luokka käsittelee kyseistä koostetta samalla tavalla ja samanaikaisesti konkreettisten aliluokkien olioiden kanssa. Ohjelma käsittelee kaikkia itsensä sisältävän koosteen osia samalla tavalla.[32]

Kuorruttaja (Decorator, Wrapper) on suunnittelumalli, jossa oliolle (ei koko luokalle) lisätään toiminnallisuutta (vastuita) ajon aikana (dynaamisesti) käyttämällä abstraktia rajapintaluokkaa, jonka alaluokat toteuttavat toiminnallisuuden. Kuorruttaminen on joustava vaihtoehto perinnälle.[33]

Julkisivu (Facade) on ohjelmiston rakennemalli, jossa julkisivu-luokka tarjoaa yhden yhtenäisen rajapinnan alijärjestelmäluokkien rajapintojen joukolle ja niiden keskeisille palveluille. Julkisivu vähentää alijärjestelmien riippuvuuksia ja niiden välistä kommunikaatiota ja helpottaa alijärjestelmän käyttöä.[34]

Hiutale (Flyweight) on ohjelmiston rakennemalli, jossa yhteiskäyttöistä oliota käytetään samanaikaisesti useissa eri yhteyksissä. Hiutale käyttäytyy jokaisessa käyttöyhteydessään itsenäisesti. Hiutaleessa olion sisäinen ja ulkoinen tila on erotettu toisistaan, sisäinen tila on tallentuneena hiutaleeseen, ja ulkoinen tila vaihtelee tilanteen mukaan ja riippuu asiayhteydestä.[35]

Edustaja (Proxy, Surrogate) on ohjelmiston rakennemalli, jossa olioille luodaan korvike (tai paikan pitäjä) käyttäen abstraktia rajapintaluokkaa, jonka alaluokka konkreettinen Edustaja-luokka on. Edustaja-luokka kontrolloi olioon kohdistuvia pyyntöjä.[36]

Käyttäytymismalli kuvaa ohjelman kulun vaihe vaiheelta (algoritmi), olioiden tehtävät (vastuut) ja olioiden suhteet toisiinsa ja niiden välisen yhteistyön (vuorovaikutus). Käyttäytymismalli kuvaa lisäksi ohjelmiston staattisen rakenteen (luokat).[37] Käyttäytymismalli voi olla luokkiin perustuva (mm. operaatiorunko- ja tulkkimalli), olioihin perustuva (mm. tarkkailija-, vastuuketju- ja välittäjämalli) tai toiminnallisuuden kapselointi olioon (mm. iteraatio-, komento-, strategia-, tila- ja vierailijamalli).[38] Käyttäytymismalli kuvaa olioiden välisen ohjelman suorituksen aikana tapahtuvan dynaamisen vuorovaikutuksen[7]

Yleisfunktio (Template Method) perustuu toimintojen delegointiin luokille perintää käyttäen. Abstraktissa rajapintaluokassa määritellään tuotantoluokkien ne toiminnallisuudet, jotka ovat samat kaikissa alaluokissa. Tuotantoluokissa määritellään ne toiminnallisuudet, joiden käyttäytyminen voi vaihdella.[38]

Tulkki (Interpreter) perustuu toimintojen delegointiin luokille perintää käyttäen. Laaditaan ohjelmointikieli, jolla voidaan määritellä haluttu toiminnallisuus. Ohjelmoidaan luokkia käyttäen tulkkausohjelma, joka kääntää kieliopin mukaiset käskyt toiminnallisuudeksi.[39]

Tarkkailija (Observer) Perustuu toimintojen delegointiin olioille käyttäen koostamista. Olioiden välinen tiedonsiirto tapahtuu tarkkailijaa käyttäen, joka muuttaa olion tiedon niissä olioissa, jotka ovat siitä riippuvaisia (yksi-moneen-suhde). Klassinen esimerkki tarkkailijasta on MVC-malli (Model-View-Controller; Luokkamalli-Näkymä-Valvoja-malli).[39]

Vastuuketju (Chain of Responsibility) perustuu toimintojen delegointiin olioille koostamista käyttäen. Olioiden välinen tiedonsiirto perustuu pyynnön mahdollisesti käsittelevien olioiden (kandidaattioliot) muodostamaan ketjuun, jossa pyyntö käsitellään siinä oliossa, joka voi toteuttaa pyynnön. Pyynnön vastaanottava (käsittelevä) olio ei ole sidottu pyynnön lähettäneeseen olioon.[39]

Välittäjä (Mediator) perustuu toimintojen delegointiin olioille koostamista käyttäen. Eri olioiden välinen tiedonsiirto tapahtuu abstraktia kapseloitua välittäjäoliota käyttäen eli vuorovaikutuksessa olevat oliot eivät voi viitata toisiinsa, edistää olioiden löyhää sidontaa.[39]

Iteraatio (Iterator) perustuu toiminnallisuuden kapselointiin olioon ja funktioiden kutsumiseen tarpeen mukaan. Esimerkiksi tietorakenteen läpikäymiseen peräkkäisjärjestyksessä käytettävä toiminnallisuus kapseloidaan olioon.[39]

Komento (Command) perustuu kutsun kapselointiin abstraktiin olioon ja funktioiden kutsumiseen tarpeen mukaan tätä oliorajapintaa käyttäen.[39]

Muisto (Memento) perustuu olion sisäisen tilan kapselointiin. Olion sisäinen tila kapseloidaan muisto-olioon, jonka tietoihin on pääsy vain tiedon lähdeoliolla.[39]

Strategia (Strategy) perustuu olion ohjelma-algoritmien kapselointiin tuotanto-olioihin, joista muodostuu tuotanto-olioperhe. Abstrakti strategiaolio ohjaa pyynnön tuotanto-oliolle.[39]

Tila (State) Perustuu olion tilan (ja tilaan liittyvän vaihtuvan toiminnallisuuden) kapselointiin abstraktin olion valitsemaan tuotanto-olioon. Kun a.oliota kutsutaan, se valitsee sen hetkisen tilansa mukaisen toiminnallisuuden toteuttavan konkreettisen olion.[39]

Vierailija (Visitor) Perustuu kutsuvien luokkien yhtäpitävän toiminnallisuuden kapselointiin tuotantoluokkaan ja funktioiden kutsumiseen tarpeen mukaan abstraktia rajapintaluokkaa käyttäen. Kutsuvien luokkien toiminnallisuutta voidaan lisätä ilman niiden luokkarakenteen muuttamista tuotantoluokkia lisäämällä.[39]