Suunnittelumallien käyttö ohjelmistosuunnittelussa Mika Rantakeisu Rovaniemen ammattikorkeakoulu Avoin ammattikorkeakoulu mika.rantakeisu@edu.ramk.fi Tiivistelmä Tämä on selvitys suunnittelumallien käytöstä ohjelmiston kehitysprosessissa. Esittelen useita käytössä olevia suunnittelumalleja ja sovellan niitä käytännössä ohjelman sovellusarkkitehtuurin luomiseen. Käsittelen myös suunnittelumallien yleistä merkitystä ohjelmistokehitykselle ja niiden hyötyjä ja haittoja ohjelmiston arkkitehtuurin luomisessa. Esittelen uusimpia ohjelmoinnin periaatteita ja sovellan niitä suunnittelumallien kanssa ohjelmistokehitysprosessissa. Näytän aikaisemmin tekemäni ohjelman sovellusarkkitehtuurin ja luon suunnittelumalleja käyttäen uuden version tämän ohjelman arkkitehtuurista. Lopuksi esittelen käyttämiäni suunnitteluratkaisuja ja analysoin näiden ratkaisujen hyötyjä ja haittoja verrattuna alkuperäiseen ohjelmaan. Suunnittelumallit ja ohjelmat esitellään tekstikuvauksena sekä UMLkaaviona. Sisällysluettelo JOHDANTO 1.0 Mitä suunnittelumallit ovat? 1.1 Suunnittelumallien hyödyt 1.2 Suunnittelumallien haitat 1.3 Ohjelmisto alan käsitteitä 2.0 SUUNNITTELUMALLIEN ESITTELYJÄ 2.1 Tila suunnittelumalli 2.2 Tarkkailija suunnittelumalli 2.3 Tehdasmetodi suunnittelumalli 2.4 Kehysmetodi suunnittelumalli 3.0 ALKUPERÄINEN OHJELMA 3.1 Mikä on Boulder Dash? 3.2 Lopputulos 3.3 Ajatus uuden version kehitystyöhön 4.0 OHJELMAN UUDELLEENKEHITYS KÄYTTÄEN SUUNNITTELUMALLEJA 4.1 Uuden sovellusarkkitehtuurin rakenne 5.0 LOPPUTULOKSET 5.1 Suunnittelumallien vaikutus ohjelmointiprosessiin 5.2 Suunnittelumallien vaikutus arkkitehtuurin suunnitteluun. 5.3 Johtopäätökset LÄHTEET JOHDANTO Suunnittelumallit ovat valmiita ratkaisuja niihin ongelmiin, joita ohjelmoija kohtaa koostaessaan tietokoneohjelman eri osia. Ne ovat loistava tapa ohjelmoijien siirtää tietoa muille ohjelmoijille suullisesti tai dokumentaation kautta. Käytän tässä julkaisussa ohjelman tilalla synonyymia sovellus. Esittelen aikaisemmin tekemäni sovellusarkkitehtuurin ja kuvaan sovelluksen toimintaa ja kuinka se on tehty. Käytän suunnittelumalleja sen sovellusarkkitehtuurin uudistamiseen ja analysoin uuden arkkitehtuurin hyötyjä sekä haittoja. Lopuksi kerron tämän prosessin aikana tekemiäni havaintoja suunnittelumallien vaikutuksesta siihen mitä ohjelmistokehitysprosessin eri vaiheissa tapahtuu. 1.0 MITA SUUNNITTELUMALLIT OVAT? Suunnittelumallit ovat tärkeä osa ohjelmistokehitysprojektia. Niitä voisi kuvata kokeneiden ohjelmoijien kansanperinteeksi, joka tarjoaa valmiita suunnitteluratkaisuja moniin toistuviin ongelmiin, joita ohjelmoija kohtaa koostaessaan tietokoneohjelman komponenttia arkkitehtuurisuunnittelussa ennalta määrättyyn tarkoitukseen vastaamaan parhaan mukaan sovelluksen spesifikaatiossa määriteltyjä toiminnallisuus- ja laatuvaatimuksia. Erilaisia suunnittelumalleja on satoja ja ne jakaantuvat käyttökontekstinsa mukaan toiminta-, rakenne- ja luontimalleihin. Rakennemalleissa määritellään miten komponentin luokat rakennetaan. Luontimalleissa määritellään miten komponentin oliot luodaan. Toimintamalleissa kuvataan miten komponentin oliot toimivat. 1.1 Suunnittelumallien hyödyt Tuntemalla suunnittelumalleja ohjelmoijat voivat siirtää keskenään paljon tietoa sovellus-spesifeihin ratkaisuihin liittyen. Päätös käyttää jotain suunnittelumallia sovelluksen komponentin tekemiseen määrittelee pitkälti sen, miten se rakennetaan ja toimii. Periaatteessa suunnittelumallia voi verrata talon rakennuspiirustuksiin, jotka määrittelevät talon rakenteen ja rakennustavan. Samoin kuin rakentajalla tehtäväksi jää talon rakentaminen rakennuspiirustusten mukaisiksi, niin ohjelmoija pyrkii ohjelmoimaan komponentin mahdollisimman pitkälle suunnittelumallin määritelmässä viitekehyksessä.
Suunnittelumallien kautta voidaan toteuttaa modernin ohjelmistokehityksen käytäntöjä, joita suositellaan sovellettavaksi sovellusarkkitehtuurin suunnittelussa. Nämä käytännöt ovat: [3, s608] 1. Suosi koostamista yli perimisen 2. Luokkien pitää olla avoimia laajennettavuutta varten, suljettuja muokkausta varten 3. Pyri löyhästi sidottuun ratkaisuun komponenttien rajapintojen ja toteutuksen välillä 4. Komponentin sisäiset ratkaisut eivät saa näkyä rajapinnan ulkopuolella 5. Suosi rajapintojen muokkausta/lisäämistä, metodien toteutuksen muuttamisen sijaan 6. Kapseloi se mikä muuttuu 7. Oliot ovat suoraan yhteydessä ainoastaan vierekkäisen arkkitehtuurikerroksen olioiden kanssa 8. Ohjelmoi rajapintoja vastaa älä toteutuksia Lisäksi modernin Java-ohjelmistokehityksen paradigma on pyrkiä siihen että, ohjelman toiminta määräytyy dynaamisesti ohjelman ajovaiheessa, ennenmin kuin se tapahtuisi staattisesti ohjelman kääntämisvaiheessa. [3, s69] 1.2 Suunnittelumallien haitat Suunnittelumallit monimutkaistavat ohjelmaa ja lisäävät erilaisten luokkien ja metodien sekä koodin määrää. Lisäksi ne luovat rajoituksia ohjelman kehitykseen. 1.3 Ohjelmisto alan käsitteitä Suunnittelumallien käyttöön liittyy monia sovellusarkkitehtuuriin liittyviä käsitteitä, jotka kannattaa ymmärtää ainakin yleisellä tasolla. Luokkaa käytetään ohjelmistosuunnittelussa mallittamaan, jonkun abstraktin tai reaalimaailman käsitteen ilmentymää ohjelmistossa. Käytännossä luokassa määritellään tietty loogiseen kokonaisuuteen kuuluva algoritmi ja mitä tietoa siihen talletetaan. Olio on luokan ilmentymä ohjelmaa ajettaessa. Ohjelman toiminnan aikana se toimii algoritmiensa mukaan, joilloin siihen kapseloidaan tietoa sekä se on yhteydessä muihin luokista toteutettuihin olioihin. Rajapinta tarkoittaa tapaa jolla oliot ovat yhteydessä toisiinsa. Kaikki olioiden väliset yhteydet eivät tapahtu rajapintojen kautta, mutta komponenttien, kerroksien ja myös moduuleilla on omia rajapintoja, joilla niihin pitää olla yhteydessä. Periaatteessa rajapinta antaa komponenttia käyttävälle asiakkaalle tietyn rajatun näkymän komponentin tietoihin ja toimintoihin. Yleensä tämä tarkoittaa vain niitä tietoja ja toimintoja, joita kyseisen asiakkaan arkkitehtuuri suunnittelun perusteella tarvitsee käyttää. Ohjelmistoprosessissa sanalla komponentti voi olla monta merkitystä. Se voi tarkoittaa luokkaa, olioden kokonaisuutta tai vain yhtä oliota. Komponentti joka tapauksessa toteuttaa tiettyjä toimintoja, joita sille on asetettu arkkitehtuurisuunnittelussa ja yhteydet komponenttiin tapahtuvat sen rajapintojen kautta näin se on helposti uudelleen käyttävissä muissa ohjelmissa kuin se jossa on määritelty. Monet ohjelmointikielet tarjoavat valmiita komponentteja, jotka on suoraan käytettävissä ohjelmassa. Moduuli voidaan määritellä luokaksi, paketiksi, komponentiksi. Moduuli on yleensä koodin hallinnallinen kokonaisuus. Ohjelma kannattaa jakaa monitasomallin mukaisiin kerroksiin. Kerros käsittää kaikki tiettyyn loogiseen kokonaisuuteen tarkoitetut oliot. Kerrokset ovat yhteydessä toisiinsa rajapintojen kautta vain monitasomallin vierekkäisten kerrosten välillä. Eri kerrokset saattavat sijaita eri tietokoneilla. Yleisin tapa jakaa sovellus kerroksiin on niin sanottu kolme kerrosarkkitehtuuri, jossa on käytössä käyttöliittymä-, toimintalogiikka-, ja infrastruktuurikerrokset. Arkkitehtuuri tarkoittaa perustaa, jonka varaan kaikki sovelluksen myöhemmät suunnittelu- ja toteutusratkaisut rakennetaan. Arkkitehtuurikuvaus toimii järjestelmän yleisrakenteen dokumentaationa.[2] 2 SUUNNITTELUMALLIEN ESITTELYJÄ Erilaisia suunnittelumalleja satoja ja ne jakaantuvat sen ongelma kontekstinsa mukaan, jonka ne ensisijaisesti ratkaisevat rakenne-, luonti-, ja käyttäytymismalleihin. Yleensä tarvitsee osata joitakin keskeisiä suunnittelumalleja. [3] 2.1 Tila suunnittelumalli Tila-suunnittelumallissa (State Pattern) määritellään rajapinta, jolla voidaan samalle oliolle määritellä monia toteutuksia niistä luokista, jotka toteuttavat rajapinnan. Tilasiirtymät voivat tapahtua ohjelman sisäisesti olion tilan mukaan tai ulkoisesti. Tila-suunnittelumalli ei ota kantaa siihen mikä muuttaa olioiden tilaa. Toteutuksessa on määriteltävä miten tila oliot luodaan ja tuhotaan.[3, s22] Käytännössä suunnittelumalli voidaan toteuttaa seuraavasti (UML luokkakaavio kuva[1]). Määritellään rajapinta (State) ja rajapinnan toteuttavia luokkia (ConcreteState1, ConcreteState2). Rajapintaa käyttävässä asiakas (Context) luokassa on jäsen muuttuja jonka tyyppi on rajapinta State. Sekä jäsenmuuttujat, jotka viittaavat State liittymän toteuttaviin ConcreteState1 ja ConcreteState2 luokkiin. Myös ConcreteState1 ja ConcreteState2 luokissa on jäsenmuuttuja joka viittaa samaan Context luokkaan. Tilojen vaihto tapahtuu niin että Context luokka asettaa State muuttujan viittaamaan milloin esimerkiksi ConcreteState1 luokkaan tai ConcreteState2 muuttujaan, näiden omien setstate(state : State) metodien kautta. [3]
tapa toteuttaa Tehdasmetodi-suunnittelumalli (virtual constructor) on seuraava (kuva[3]). Suunnittelumallissa on yliluokka (Object), josta määritellään aliluokkia (ConcreteObject1, ConcreteObject2). Suunnittelumallissa on FactoryMethod-niminen luokka, jossa on factory niminen metodi. Tämä metodi luo oliota Object yliluokan aliluokista, Joita on esimerkiksi ConcreteObject1 ja ConcreteObject2.[3] kuva[1] Tila-suunnittelumalli sopii ohjelmiin, joissa olion käyttäytyminen riippuu tilasta ja olion on vaihdettava käyttäytymistään ajon aikana. Esimerkki tällaisesta on TCP-yhteys, jossa kolme tilaa jotka ovat suljettu, muodostettu ja kuuntelee.[1] 2.2 Tarkkailija suunnittelumalli Tarkkailija-suunnittelumallissa (Observer-pattern) määritellään Subject rajapinnan toteutta olio (kuva[2]) (ConcreteSubject) sekä ConcreteObserver oliota, jotka toteuttavat Observer rajapinnan. ConcreteSubject oliossa on viittaus ConcreteObserver oliohin (yleensä jonkinlainen lista). Ja samoin ConcreteObserver oliossa on viittaus samaan ConcreteSubject olioon. [3, s52] Tarkkailijan toiminta tapahtuu niin että Concrete- Observer rekisteröi itsensä ConcreteSubject olion tarkkailijaksi (lisää itsensä listaan). Jos Concrete-Subject olion tila muuttuu niin se ilmoittaa siitä kaikille Tarkkailijoilleen (ConcreteObserver oliot listassa), jotka muuttavat omaa toimintaansa. ConcreteSubject tilan mukaan. Jokainen ConcreteObserver olio voi lisätä ja poistaa itsensä listasta koska tahansa.[3] kuva[3] Tehdasmetodi suunnittelumallia käytetään sovelluksissa, joissa ei tiedetä mitä eri oliota milloinkin käytetään eri tilanteissa sovelluksen ajon aikana.[1] 2.4 Kehysmetodi suunnittelumalli Kehysmetodi-suunnittelumalli (kuva[4]) on perussuunnittelumalleja. Siinä määritellään yliluokka, jonka aliluokat perivät laajentaen ja muuttaen yliluokan toimintaa. kuva[4] Kehysmetodia käytetään laajasti ohjelmoinnissa. Itse asiassa tavallinen luokanperintä toteuttaa kehysmetodisuunnittelumallin. kuva[2] Tarkkailija suunnittelumalli sopii hyvin järjestelmiin, joissa järjestelmän tietyn olion tilan muuttuessa halutaan tiedottaa siitä järjestelmän muihin olioihin ilman että tarvitsee tietää minkälainen tämä olio on. Olion tarvitsee vain toteuttaa vaaditut Subject ja Observer rajapinnat. Tarkkailija on kaikkein yleisimmin käytetty suunnittelumalli. 2.3 Tehdasmetodi suunnittelumalli Tehdasmetodi suunnittelumallissa luodaan halutun yliluokan toteuttavia olioita algoritmin mukaan. Yksi 3 ALKUPERÄINEN OHJELMA Tein alkuperäisen ohjelman heinä-elokuussa 2011. Halusin kehittää ohjelmointitaitojani ja etsin siihen sopivaa haastetta. Keksin että voisin tehdä oman version klassisen Commotore 64 pelistä nimeltään Boulder Dash. Kyseinen peli tuntui sopivalta haasteelta kehittää ohjelmointitaitojani.
3.1 Mikä on Boulder Dash? kuva[5] Boulder Dash (kuva[5] ja kuva[6]) on kaksiulotteinen toiminnallinen pulmanratkontapeli, jossa pelaaja kaivautuu kentän läpi keräten tietyn määrän timantteja päästäkseen seuraavaan kenttään. 3.2 Lopputulos Ohjelmoin Boulder Dash pelin Java-ohjelmointikielellä. Tuolloin en varsinaisesti suunnitellut ohjelmaa, vaan koostin sen askel askeleelta kehittäen siihen vaadittuja ominaisuuksia, joita olin siihen määritellyt vaatimusmäärittelyssä. Tuloksena oli vaatimusmäärittelyn toiminnallisenmäärittelyn kohtuudella täyttävä, mutta laatuvaatimukset huonosti toteuttava ohjelma, jonka koodia ulkopuolisten oli vaikea ymmärtää. Sovelluksen koodissa ei juurikaan ollut mitään rakennetta, enkä käyttänyt edes olio-ohjelmoinnin yleisiä perusperiaatteita, joita on esimerkiksi periminen ja kapselointi sekä saman olion käyttö useassa kohteessa. Vaan loin jokaista toiminnallisuutta varten oman olion, joka oli hyvin monesti hyvin samanlainen jo toteuttamieni olioiden kanssa. Myös sellaiset käsitteet kuin komponentti ja rajapinta olivat minulle tuntemattomia. Kuitenkin huonoin sovellusarkkitehtuurin (kuva[7]) ratkaisu oli se että, suurin osa koodista sijaitsi yhdessä luokassa nimeltään Peli. Tämä teki Peli-luokasta todella suuren ja vaikeasti ymmärrettävän. Arkkitehtuuri kannalta sovelluksen luokat olivat tiukasti sidottu toisiinsa (vertaa periaate 3). Eikä sen koodia voinut siksi käyttää muissa ohjelmissa. Koodi oli muutenkin epäjohdonmukaista ja huonosti suunniteltua. Alkuperäisen ohjelman sovellus-arkkitehtuuri on kuvassa 7. kuva[6] kuva[7] 3.3 Ajatus uudenversion kehitystyöhön Ajatus uuden version tekemiseen syntyi, kun aloin perehtymään sellaisiin ohjelmoinnissa keskeisiin käsitteisiin kuin monisäikeisyys, rajapinta, komponentti ja ennen kaikkea suunnittelumallit. Opin myös monia
yleisiä ohjelmoinnin periaatteita, joita kannattaa soveltaa ohjelmien kehityksessä. Ymmärsin pystyisin tekemään ohjelmasta laatuvaatimukset paremmin toteuttavan version. 4 OHJELMAN UUDELLEENKEHITYS KÄYTTÄEN SUUNNITTELUMALLEJA Vaatimusmäärittelyn pohjalta tein arkkitehtuurisuunnitelman, jossa päädyin käyttämään seuraavia suunnittelumalleja Tehdasmetodi, Tila, Kehysmetodi sekä Tarkkailija. Käytän myös modernin ohjelmistokehityksen yleisiä periaatteita ohjelman toteutuksessa. Myös Java Code Conventions tyylioppisääntöjä käyttäminen muuttujien ja luokkien nimeämiseen on tärkeää saadakseni ohjelmasta enemmän standartien ja käytäntöjen mukaiseksi, tämä tekee ohjelmasta ymmärrettävämmän. Ohjelman suoritus tulee myös jakaantumaan usealle säikeelle. Uudistettu sovellusarkkitehtuuri näkyy kuvassa 8. 4.1 Uuden sovellusarkkitehtuurin rakenne Uudessa arkkitehtuurissa (kuva[8]) on toteutettu Tarkkailija-suunnittelumallia Peli-luokan ja KäyttoLiittyma -luokan välillä, joka nimensä mukaisesti toimii käyttöliittymänä peliin. Peli luokka toteuttaa Subject-rajapinnan ja KayttoLiittyma-luokka toteuttaa Observer rajapinnan. Tämän suunnittelun suurin hyöty on se että Peli luokalla voi olla lukuisia erilaisia käyttöliittymiä, joita voidaan käyttää ja vaihtaa dynaamisesti ohjelman ajon aikana. Peli luokalla voi olla jopa useita käyttöliittymiä yhtä aikaa. Mutta on epäselvää onko tästä hyötyä tässä vaiheessa. kuva[8] KeyListener rajapinta (Interface) ja NappainKuuntelija luokka toteuttavat Kehysmetodi-suunnittelumallia. KeyListener rajapinnan toimintaa laajennetaan ja muutetaan NappainKuuntelija luokassa. Haamu ja TuliKarpanen luokissa on jäsenmuuttujina Liikkuminen niminen rajapinta tyyppinen jäsenmuuttuja sekä Liikkuminen liittymän toteuttaviin LiikkuuVasempaan ja LiikkuuOikeaan luokkiin viittaavia jäsenmuuttujia. Haamu ja TuliKarpanen vaihtavat Liikkuminen tyyppisen muuttujan viittaamaan ajon aikana dynaamisesti, joko LiikkuuVasempaan tai LiikkuuOikeaan luokasta muodostettuun olioon. Nämä luokat toteuttavat yhdessä Tila-suunnittelumallin. TehdasMetodi luokka toteuttaa luonnollisesti TehdasMetodi-suunnittelumallin. TehdasMetodiluokalla luodaan ohjelman ajon aikana dynaamisesti abstraktin PeliHahmo-luokan toteuttavia oliota (esimerkiksi Kivi, Haamu, TuliKarpanen). Sovelluksessa on nyt määritelty komponentteja, joita voi käyttää muissa ohjelmissa. Komponentti 1 on samalla käyttöliittymäkerros. Siinä on kaikki sovelluksen käyttöliittymään osat. Siihen ollaan yhteydessä tarkkailija-suunnittelumallin Observerrajapinnan kautta. Komponentti 2 taas tarjoaa rajapinnan kuunnella näppäin komentoja. Komponenttiin ollaan yhteydessä KeyListener rajapinnan kautta. Komponentti 3 tarjoaa erilaisia algoritmi ratkaisuja näytön komponenttien liikkumiseen. Sovellus voidaan myös jakaa eri kerroksiin monikerrosmallin mukaisesti. Yleisimmin käytetään kolme kerron arkkitehtuuria (three tier architecture), jossa sovellus on jaettu käyttöliittymä-, toimintalogiikka- ja infrastruktuuri kerroksiin. Tässä tapauksessa voidaan nähdä että sovellus on jakaantunut käyttöliittymä kerrokseen ja toimintalogiikka kerrokseen. Käyttöliittymä kerrokseen kuuluu KayttoLiittyma ja Observer luokat. Kaikkien muiden luokkien kuuluessa toimintalogiikka-kerrokseen. Kyseessä on kaksi kerros arkkitehtuuri. PeliHahmojenKasittely-luokka perii Runnable-luokan, joka mahdollistaa sen että metodien kutsut PeliHahmojenKasittely luokassa voidaan suorittaa omassa säikeessään käyttämällä run()-metodia. Sovelluksen suoritus on näin jaettu monelle säikeelle. 5 LOPPUTULOKSET Suunnittelumalleista oli hyötyä sekä ohjelman suunnittelussa ja sekä ohjelmoinnissa. 5.1 Suunnittelumallien vaikutus ohjelmointiprosessiin Suunnittelumallien hyöty sovelluksen kehityksessä tuli esiin jo sovelluksen arkkitehtuurin suunnittelu vaiheessa. Päätös käyttää jotain suunnittelumallia sovelluksen komponentin tekemiseen määrittelee pitkälti sen miten se rakennetaan ja toimii. Suunnittelumallien kautta voidaankin suullisesti ja dokumentaation kautta jakaa sellaista tietoa ohjelmointiprosessista, jota muuten on vaikea siirtää.
Itse sovelluksen ohjelmointiprosessin suunnittelumallin käyttäminen teki johdonmukaisen tavoitetietoisen tapahtuman, koska suunnittelumallin käyttö tietyn komponentin tekemiseen antaa viitekehyksen miten se rakennetaan. Kun komponentti rakennetaan ennalta määrätyllä tavalla vastaamaan toiminnallisuus vaatimuksia on eri suunnitteluratkaisujen vaikutus lopputulokseen paremmin ennakoitavissa. Eikä ohjelmoijan enää tarvitse ratkoa miten komponentti on parhainta rakentaa, näin säästetään paljon aikaa sovelluksen kehityksessä ja vähennetään mahdollisuutta ennalta odottamien ongelmien syntymiseen ohjelmaa kehitettäessä. 6 LÄHTEET [1]Immonen Mirja, Suunnittelumallit Kuopion yliopisto http://cs.uef.fi/uku/tutkimus/teho/suunnittelumallit.pdf [2]Helsingin yliopisto, Ohjelmistojen mallintaminen, arkkitehtuuria ja rajapintoja http://www.cs.helsinki.fi/u/pohjalai/ke09/ohma/slides/oh ma_08-arkkitehtuurisuunnittelua.pdf [3]Eric Freeman, Elisabeth Robson, Bert Bates, Kathy Sierra 2004 Head First Design Patterns: O'Reilly Media 5.2 Suunnittelumallien vaikutus arkkitehtuurinsuunnitteluun Ohjelmointikontekstista katsottuna uusi arkkitehtuurisuunnittelu tekee ohjelmointiprosessista enemmän rajapintoja vastaan ohjelmointia ja on komponentteihin perustuvaa. Näin on toteutettu monia modernin ohjelmistokehityksen periaatteita, joita on esimerkiksi pyri löyhään sidontaan rajapintojen ja toteutusten välillä (periaate 3) sekä komponenttien sisäiset ratkaisut eivät näy rajapinnan ulkopuolelle (periaate 2). Lisäksi toiminnallisuutta voidaan tulevaisuudessa laajentaa tai muuttaa rajapintoja muokkaamalla. Ennemmin kuin muutettaisiin metodien toteutuksia (periaatteet 4, 5). Ohjelma on helpommin skaalattavissa ja sen komponentteja voidaan uudelleen käyttää muissa ohjelmissa, joissain tapauksissa eri ohjelmat voivat jopa jakaa saman komponentin. Ohjelmasta tulee paremmin tarkoitukseen sopiva, johdonmukaisempi, helpommin muiden ymmärrettävä. Lisäksi ohjelmistokehitysprojektissa sovelluksen kehitys voidaan jakaan komponentteihin, jonka kukin ohjelmoija voi tehdä itsenäisesti. Ohjelmoijan tarvitsee tietää vain komponenttien rajapinnat (periaate 8). Koostamalla (periaate 1) on voitu kapseloida se mikä eri luokissa muuttuu omiin luokkiinsa (periaate 6) näin on myös toteutettu modernin Java-ohjelmisto-kehityksen paradigma eli toiminnallisuuden määrittely (luokkien liittäminen toisiinsa) tapahtuu nyt ennemmin dynaamisesti ohjelman ajon aikana kuin staattisesti perimällä. Ohjelman sovellusarkkitehtuuri voidaan nyt myös jakaa toimintalogiikka- ja käyttöliittymäkerroksiin. Käyttöliittymäkerros ja toimintalogiikka kerrokset ovat yhteydessä keskenään Tarkkailija-suunnittelumallin rajapintojen kautta, näin sovellus täyttää periaatteen 7 ohjelmistokehitykseen liittyen. 5.3 Johtopäätökset Suunnittelumalleista oli paljon hyötyä ohjelman kehityksessä eri ohjelmistokehityksen eri vaiheissa ja arkkitehtuurin suunnittelussa.