Ohjelmoinnin peruskurssien laaja oppimäärä

Ohjelmoinnin peruskurssien laaja oppimäärä Luento 13: Isomman ohjelman suunnittelusta, suunnittelumalleja Riku Saikkonen (merkityt ei-laajan kurssin kalvot: Otto Seppälä) 3. 2. 2011

Sisältö 1 Top-down- ja bottom-up-menetelmät 2 Suunnittelusta 3 Defensive programming 4 Muutama suunnittelumalli

Top-Down Top-down toteutuksessa ja suunnittelussa aloitetaan koko järjestelmän suunnittelusta Tämä määrittely on hyvin suurpiirteinen Määrittely jakaa järjestelmän alijärjestelmiin ja kertoo järjestelmän tasolla kuinka se käyttää alijärjestelmiä joiden kuvitellaan olevan olemassa Yllämainittu toistetaan alijärjestelmän tasolla Alijärjestelmä kuvataan käyttäen apuna pienempiä osasia Lopulta päästään alimmalle tasolle Yksittäiset luokat, metodit Todennäköisesti suunnitelmaa pitää tarkentaa useaan kertaan ennenkuin se on toteutettavissa 00:31

Top-Down Suunnitellessa määritellään järjestelmien ulkoiset rajapinnat ennen niiden toteutusta Toteutettaessa koodi rakennetaan käyttämään osia joita ei vielä ole olemassa Voidaan kirjoittaa tynkiä jotta päästään testaamaan...ja kääntämään Kirjoita ensimmäinen versio pseudokoodilla Älä kiinnitä alussa lainkaan huomiota syntaksiin tms. Kun runko on kasassa on suunnittelua helppo tarkentaa 00:31

Top-down-menetelmän ongelmia top-down-menetelmällä voi päätyä suunnittelemaan pitkäänkin ennen kuin kokeilee suunnitelman toimivuutta käytännössä usein vasta ohjelmoidessa huomaa, ettei suunniteltu rajapinta toimikaan hyvin jos suuri osa muusta ohjelmasta on jo valmiiksi suunniteltu, rajapintojen muuttaminen voi olla työlästä suunnitelmasta saattaa unohtua ominaisuus, jota on hankala lisätä siihen jälkeenpäin tai siihen voi tulla turhaa monimutkaisuutta esim. suunnitellaan (ehkä tehdäänkin) monipuolinen apukirjasto, josta loppujen lopuksi tarvitaankin vain yksinkertaista erikoistapausta

Bottom-up Bottom-up strategia taas lähtee liikkeelle yksittäisistä osasista ja yhdistää niitä kierros kerrallaan suuremmiksi kokonaisuuksiksi Ohjelmointi ja testaus voidaan aloittaa heti Osasten yhdistely myöhemmin voi olla hankalaa koska ne on suunniteltu itsenäisesti Bottom-up tukee koodin uudelleenkäyttöä Vanhat osat saadaan sellaisenaan käyttöön Top-down suunnittelussa syntyvät rajapinnat eivät välttämättä sovi sellaisenaan vanhalle koodille 00:31

Bottom-up-menetelmän ongelmia bottom-up-menetelmässä ohjelmoidaan yksittäisiä palasia miettimättä kovin paljon sitä, miten ne sopivat yhteen rajapinnat voivat olla sekavia moduulijako voi olla huono: eri moduulit eivät ole itsenäisiä tai riippuvat toisistaan syklisesti yleinen tapa, jonka ongelmat muistuttavat bottom-upia: tehdään aluksi nopeasti pieni prototyyppi ai niin, siihen pitää vielä lisätä... ja lopulta suunnittelematta tehty prototyyppi jääkin käyttöön, koska se tekee jo niin paljon, ettei sitä ehditä toteuttaa uudelleen oikein

Top-Down + Bottom-Up Design Top-Down, Implement Bottom-Up Paras lopputulos saadaan yhdistämällä Top-down suunnittelulla vältetään moduulien yhteensopivuusongelmia ja saadaan kokonaiskuva projektista Yhdistettynä Bottom-up suunnitteluun koodin uudelleenkäyttö helpottuu Bottom-up toteutuksella päästään (yksikkö)testaamaan koodin osaset heti niiden valmistuessa 00:31

Entä käytännössä? sopiva yhdistelmä top-down- ja bottom-up-menetelmiä riippuu tilanteesta ja ohjelmoijista jotkut ohjelmat vaativat enemmän suunnittelua kuin toiset esim. ohjelma tekee monimutkaisia asioita tai on iso tai sen toimivuus tai turvallisuus on tavallista tärkeämpää jotkut vähemmän ohjelman rakenne voi olla etukäteen pitkälle tiedossa (esim. edellisestä versiosta tai muista samanlaisista ohjelmista) tai se on yksinkertainen (onkohan tosiaan?) joskus tätä ei tiedä etukäteen esim. tekee jotain niin uutta, ettei etukäteen tiedä, mitä ohjelman pitäisi tehdä tai miten se kannattaa tehdä usein (melkein aina?) ohjelman tavoitteet muuttuvat sitä tehdessä

Design Suunnittelussa ohjelma kannattaa jakaa jonkinlaisiin alijärjestelmiin Tarpeettomia riippuvuuksia näiden välillä vältettävä Sykliset riippuvuudet voivat aiheuttaa ongelmia Esimerkki : Käyttöliittymän ja logiikan erottaminen GUI ohjaa, pyytää tietoa Aivot Logiikka (pelin logiikka, numeroilla tehtävä simulointi, tietokanta jne) kirjoitetaan itsenäiseksi osaksi joka ei tiedä millaisella käyttöliittymällä sitä käytetään. Pohdi millaisia metodeja luokkien julkiseen rajapintaan tarvitaan että eri käyttöliittymät voivat ohjata logiikkaa ja hekea tietoa Käyttöliittymä (GUI) on oma osionsa. Käyttäjän toimet kutsuvat GUI:n kautta logiikan metodeita. 00:31 Käyttöliittymä hakee logiikalta ruudulla näyttämänsä tavaran.

Esimerkki Ristinolla-peli Logiikka GUI Pelilauta.java (Kuvaa pelilautaa: merkintöjen lisäys, voittotilan havaitseminen jne) Pelaaja.java (Rajapinta: 1 metodi jolla kerrotaan että nyt on pelaajan vuoro) Katsoja.java (Rajapinta: 1 metodi jolla kerrotaan että pelilauta päivittyi) TietokonePelaaja (täyttää rajapinnan pelaaja) Joitakin graafisia elementtejä jotka piirtävät pelilaudan Pelilautaluokalta pyytämänsä datan perusteella. Jokin luokka täyttää rajapinnan Katsoja. Tämä päivittää graafisen 00:31 näkymän. Vastaavasti jokin luokka täyttää rajapinnan Pelaaja.

Design Model-View-Controller Tämä suunnittelumalli menee vielä askeleen pidemmälle, erottaen GUI:n osat(controller) jotka muuttavat mallia(model) ja osat(view) jotka vain esittävät mallin sisältämää tietoa Controller Tiedot päivittyivät ohjaus muutoskäskyt View Esitettävän datan kysely Tiedot päivittyivät, käy kysymässä Model 00:31

Lisää ModelViewControllerista Model, malli: sisältää ohjelman tallettaman datan ja tavat kysellä ja muuttaa sitä usein myös lähettää tietoja muutoksista niitä pyytäneille datan esitysmuotoa voisi vaihtaa pelkkää mallia muuttamalla joskus osa mallista on tietokannassa View, näkymä: käyttöliittymä tai erityisesti sen osa, joka näyttää asioita sillä voi olla omaa tilaa, jota esim. ei talleteta (mikä kohta datasta on tällä hetkellä näkyvissä?) perusideaan kuuluu, että näkymiä voisi olla yhtäaikaisesti monta erilaista (joskus onkin) Controller, ohjain: mallia muuttavat osat ohjelmasta (käyttöliittymästä ja automaattisesti esim. laskemalla) ei kerro näkymälle datasta (näkymä hakee ne mallilta)

Design Turhien riippuvuuksien välttäminen kannattaa myös alemmilla tasoilla Toisaalta samasta tiedosta ei yleensä kannata pitää useita kopioita Yhtä päivitettäessä pitää aina päivittää muutkin Myös riippuvasta datasta olevat kopiot voivat olla ongelmallisia Tällöin riippuvan datan turha uudelleenlaskeminen voi olla hyödyllistä. 00:31

Lisää suunnitteluvaihtoehtoja joskus suunniteltava ohjelma kannattaa jakaa osiin useampi ohjelma tai (yleiskäyttöisiä) kirjastoja + ohjelma joskus näitä osia voi yhdistää monella tavalla usein niitä voi käyttää yksinään (ei välttämättä kätevästi) hyödyllinen ajattelutapa: rajapinta voi olla kieli oikea pieni kieli, jota esim. tulkataan tai kokoelma funktioita, jotka on nimetty niin että niitä käyttävä koodi muistuttaa kieltä (esim. SICPin picture language-esimerkki) tai niin yleiskäyttöisiä funktioita, että niitä voi käyttää yhtä monipuolisesti kuin kieltä (esim. listankäsittelyfunktiot?) joskus kannattaa yleistää jos rajapinta vaikuttaa monimutkaiselta, voi olla parempi jakaa se geneerisempiin osiin mutta liika abstrahointi johtaa vaikeasti lähestyttävään koodiin

Design Mistä tiedetään, mitä luokkia pitäisi laatia tietyn ongelman ratkaisemiseksi? Millaisia kenttiä ja metodeita niille tulee? Ei ole yhtä parasta ratkaisua. Suunnittelutavoitteet voivat olla ristiriitaisia tasapainottelu, kompromissit. Ei ole menetelmää, jolla päästään varmasti hyvään tulokseen. Ei ole yleispätevää tapaa selvittää, onko jokin ratkaisu hyvä tai huono. Useimmille nyrkkisäännöille löytyy tapauksia, joissa kannattaakin toimia toisin. 00:31

Esimerkkejä nyrkkisäännöistä Ovatko nämä totta tai kannattaako niitä noudattaa? yli 50-rivinen funktio tai metodi on liian pitkä

Esimerkkejä nyrkkisäännöistä Ovatko nämä totta tai kannattaako niitä noudattaa? yli 50-rivinen funktio tai metodi on liian pitkä jos funktiollasi on 10 argumenttia, olet unohtanut yhden

Esimerkkejä nyrkkisäännöistä Ovatko nämä totta tai kannattaako niitä noudattaa? yli 50-rivinen funktio tai metodi on liian pitkä jos funktiollasi on 10 argumenttia, olet unohtanut yhden jos kopioit koodia, viiden minuutin sisällä joudut muuttamaan molempia kopioita

Esimerkkejä nyrkkisäännöistä Ovatko nämä totta tai kannattaako niitä noudattaa? yli 50-rivinen funktio tai metodi on liian pitkä jos funktiollasi on 10 argumenttia, olet unohtanut yhden jos kopioit koodia, viiden minuutin sisällä joudut muuttamaan molempia kopioita tee kentille aina get- ja set-metodit

Esimerkkejä nyrkkisäännöistä Ovatko nämä totta tai kannattaako niitä noudattaa? yli 50-rivinen funktio tai metodi on liian pitkä jos funktiollasi on 10 argumenttia, olet unohtanut yhden jos kopioit koodia, viiden minuutin sisällä joudut muuttamaan molempia kopioita tee kentille aina get- ja set-metodit älä käytä julkisia kenttiä (yleisemmin: älä käytä kielen ominaisuutta X)

Esimerkkejä nyrkkisäännöistä Ovatko nämä totta tai kannattaako niitä noudattaa? yli 50-rivinen funktio tai metodi on liian pitkä jos funktiollasi on 10 argumenttia, olet unohtanut yhden jos kopioit koodia, viiden minuutin sisällä joudut muuttamaan molempia kopioita tee kentille aina get- ja set-metodit älä käytä julkisia kenttiä (yleisemmin: älä käytä kielen ominaisuutta X) älä keksi pyörää uudestaan (vaan käytä melkein oikealla tavalla toimivaa valmista kirjastoa)

Verb/Noun method Verb/Noun-method Yksi kirjallisuudessa esitelty tekniikka tehdä ensimmäinen malli ohjelman luokkarakenteesta 1)Kirjoitetaan lyhyehkö mutta tarkka sanallinen kuvaus ohjelman toimintavaatimuksista 2)Etsitään kuvauksesta kaikki verbit ja substantiivit 3)päätetään mitkä substantiiveista ovat luokkia, mitä näiden luokkien kenttiä 4)päätetään mitkä verbeistä ovat luokkien metodeja Vain alustava malli Kun ensimmäinen malli on saatu pohdittua niin sitä ryhdytään muokkaamaan ja tarkistetaan voidaanko sen avulla todella toteuttaa vaatimukset. 00:31

Use caset ja mallin kehittäminen Kun alustava malli on rakennettu, kokeile sitä jo ennen koodausta erilaisilla käyttöskenaarioilla Esim. Kuinka ja mitä metodeja kutsuttaisiin jos käyttäjä siirtää rahaa tililtä toiselle? Miten metodit tilisiirrossa kutsuvat toisiaan? Millaisia parametreja pitäisi laittaa? Löytyykö luokista tarvittavaa dataa. Muokkaa ja tarkenna mallia käymällä läpi joukko erilaisia käyttötapauksia. Kun olet tyytyväinen alustavaan malliin voit aloittaa koodailun. Malli tulee varmasti muuttumaan vielä koodausvaiheessa 00:31

Pohdintaa ohjelman suunnittelu on eniten luovuutta ja kekseliäisyyttä vaativa osa ohjelmoinnissa ellei sitten sen suunnittelu, mitä ohjelman pitäisi tehdä... tarkkoja sääntöjä ei ehkä kannata edes etsiä? suunnittelu on osin taidetta (kuinka paljon?) onkohan ohjelmoinnissa tyylisuuntia kuten taidehistoriassa? (esim. olio-ohjelmointi?) useimmissa taidemuodoissa tyylisuunnista yksi kerrallaan on hallitseva (jonkin aikaa ja tietyllä alueella) joskus suunnittelun taustalla on (ollut?) pyrkimys löytää oikea tapa tehdä jokin tietty asia, The Right Thing esim. SICPin symbolinen derivoija taisi syntyä 60-luvulla tällaisesta pyrkimyksestä suunnittelua oppii harjoittelemalla, mutta myös lukemalla muiden tekemiä ohjelmia

Defensive Programming Mieti miten kirjoittamaasi metodia tai luokkaa voitaisiin käyttää väärin Todennäköisesti väärinkäyttö johtuu väärinymmärryksestä Koodin käyttäjä kutsuu metodeja A ja B väärässä järjestyksessä Käytetään vääräntyyppisiä parametreja jne...mutta omat ohjelmointivirheetkin saattavat hyvin kutsua metodeja laittomilla arvoilla... ja varaudu näihin tapauksiin Jos mahdollista, rakenna koodi niin että sitä ei voi väärinkäyttää tai tarkista metodien syötteet jne. Helpottaa virheiden löytämistä : Jos metodia kutsutaan väärillä arvoilla, niin virhe ei ilmaannu metodin sisällä -> osataan aloittaa 10:03 kutsuvasta koodista

Defensive Programming Työkalut if-lauseet ja poikkeukset Jos metodilla on rajoitteita sen suhteen millaisia parametreja se voi ottaa vastaan, kannattaa ne tarkistaa ja tarvittaessa heittää poikkeus tai palauttaa jokin metodin dokumentaatiossa sovittu arvo. assertiot Javassa on Junit:in assertxxx komentoja vastaava oma assert()- metodi, joka toimii jotakuinkin vastaavalla tavalla. Paikkoihin, joissa muuttujien arvojen tulee ehdottomasti olla tietyissä rajoissa voi kirjoittaa assertioita, jotka katkaisevat ohjelman suorituksen virhetilanteessa. Nämä voi kytkeä pois käännettäessä testaus Kokeile käyttää luokkaasi väärin ja katso ettei se onnistu. 10:03

Defensive Programming Työkalut final Määreellä final voi estää metodin korvaamisen aliluokissa. Luokkaan sovellettuna final estää aliluokkien tekemisen. Määreellä voi suojata metodit tai luokat joiden korvaaminen aliluokilla voisi rikkoa niitä käyttävän luokan toiminnan, tms. private Suojaa private-määreellä apumetodit jotka on tarkoitettu luokan sisäiseen käyttöön. Vastaavasti luokan kenttien näkyvyys tulisi olla lähtökohtaisesti private josta poiketaan vain hyvillä syillä. koodin muokkaaminen 10:03

Ehtojen valitseminen kumpi näistä on parempi? for (int i = 0; i < n; i++) {... } for (int i = 0; i!= n; i++) {... } (olettaen, että silmukan sisällä i:tä muutetaan joissain tilanteissa) jotkut suosittelevat jälkimmäistä jos jokin menee pieleen, vika löytyy todennäköisemmin tästä kohdasta koodia eikä vasta myöhemmin yleisesti: ei tehdä ehdoista liian sallivia (tai: tehdään koodista haurasta, jotta se hajoaisi heti kun jokin menee vähän väärin) esim. assertio i:n arvolle olisi toki varmempi tapa löytää vika tähän ei taida olla oikea vastausta...

Suunnittelumalli Mikä on suunnittelumalli (Design Pattern) Suunnittelumalli on tiiviisti esitetty yleinen kuvaus jostakin toimivasta ratkaisusta yleiseen ongelmaan. Suunnittelumallien ideoita voi käytettäessä soveltaa vapaasti. Malleja voi myös yhdistellä, ja niin usein tehdäänkin. Vertailukohtana voi ajatella vaikkapa erilaisia puuliitostapoja, tanssiliikkeitä, Niksi-pirkan vinkkejä jne. Suunnittelumalli kuvaa yleisen ratkaisutavan ja sovellusalue lopulta määrää sen kuinka mallia kulloinkin käytetään. 10:03

Sunnittelumallit ja olio-ohjelmointi yleensä suunnittelumallit liittyvät olio-ohjelmointiin usein vielä Java-tyyppiseen olio-ohjelmointiin (esim. rajapintoja, ei moniperintää, ei ensimmäisen luokan funktioita tai metodeja) niiden idea toki toimisi muuallakin, mutta käytännössä niitä ei kovin usein näe yhtä vakiintunutta terminologiaa tai esitystapaa ei ole jotkut abstraktit funktiot (esim. fold-left) ovat mallien kaltaisia, mutta suoraan koodina monet tavallisimmista suunnittelumalleista ovat ratkaisuja nimen omaan olio-ohjelmointiin liittyviin ongelmiin joskus esim. ensimmäisen luokan funktiolla tai muuten ei-olio-ohjelmoinnilla saisi tehtyä helpomman ratkaisun mutta varsinkin puhtaassa olio-ohjelmoinnissa suunnittelumalleista on paljon hyötyä

Gang of Four Patterns Seuraavaksi käydään läpi joitakin kirjassa Gamma, Helm, Johnson, Vlissides : Design Patterns Elements of Reusable Object-Oriented Software, 1995 esiteltyjä suunnittelumalleja. Tässä kirjassa esitettyjä malleja kutsutaan yleisesti nimellä Gangof-Four patterns kirjan neljän kirjoittajan mukaan. Seuraavat kalvot perustuvat k.o. kirjaan. Näistä malleista löytyy runsaasti materiaalia verkosta 10:03

Adapter Ongelma : Jokin osa olemassaolevaa koodia toimii tietyn rajapinnan täyttävien olioiden kanssa. Tarjolla olevien olioiden luokka ei kuitenkaan täytä tätä rajapintaa. Alkuperäistä luokkaa ei kuitenkaan haluta muuttaa. Ratkaisu : Adapter sovittaa jonkin olemassaolevan luokan rajapinnan muotoon, jota jokin toinen osa ohjelmasta odottaa. Tästä suunnittelumallista on kaksi versiota : olioadapteri luokka-adapteri 10:03

Adapter - olioadapteri Toteutus : Käyttävä luokka tekee kaiken toimintansa adapteri-olioiden kanssa, jotka täyttävät vaaditun rajapinnan. Adapterioliosta on viittaus varsinaiseen olioon Rajapinnan mukaiset metodikutsut delegoidaan viittauksen kautta eteenpäin oikealle oliolle Käyttävä Luokka Tuttu Rajapinta Adapteri Käytettävä Luokka 10:03

Adapter - luokkadapteri Adapteri voi myös periä luokan (jos mahdollista), jonka rajapintaa se muuttaa. Tällöin adapteri täyttää rajapinnan vaatimat metodit, joiden tehtävä on kutsua yliluokan metodeja. Käyttävä Luokka Tuttu Rajapinta Adapteri Käytettävä Luokka 10:03

Adapteri Esimerkki: List-olion joka sisältää Comparable rajapinnan täyttäviä olioita saa automaattisesti järjestettyä Collections-luokasta löytyvällä sort-metodilla. Robotti-luokan oliot haluttaisiin järjestää painon mukaan, mutta luokka ei täytä Comparable-rajapintaa. Ratkaistaan ongelma sovitinluokalla : public class VertailuSovitin extends Robotti implements Comparable { } public int compareto(object other){ if (this.annapaino() < other.annapaino()) return -1; else if (this.annapaino() == other.annapaino()) return 0; return 1; } 10:03

Factory Method Tehdasmetodi on metodi, jota käytetään olion luontiin konstruktorin sijaan Tyypillisesti metodi on nimeltään newinstance Käytännössä metodi toimii kuten konstruktori, palauttaen viittauksen halutun tyyppiseen olioon Voidaan toteuttaa kutsumalla konstruktoria metodin sisällä Voidaan palauttaa jokin olemassaoleva halutun tyyppinen olio Voidaan tehdä temppuja oliolle ennen kuin se palautetaan 10:03

Factory Method Factory method mallia käytetään mm. kun: 1) metodia kutsuva luokka ei itse voi tietää minkä aliluokan olion se haluaa luoda Esimerkiksi on rakennettu tietorakenne joka sisältää luokan Happening olioita. Nyt Happening-luokkaan lisätään uusia kenttiä tekemällä uusi luokka EnhancedHappening joka periytyy luokasta Happening. tietorakenteen metodit tekevät kuitenkin automaattisesti Happening-olioita uuden luokkamme sijaan -> pitäisi kirjoittaa ne kaikki uudelleen jokaiselle aliluokalle Jos Happening luodaankin tehdasmetodilla konstruktorin sijaan, voidaan tehdasmetodi korvata aliluokassa -> ongelma ratkaistu! Happening-luokassa EnhancedHappening-luokassa public Happening newinstance(){ public Happening newinstance(){ return new Happening(); return new EnhancedHappening(); 10:03 } }

Factory Method Factory method mallia käytetään mm. kun: 2)kun luotavat oliot halutaan parametrisoida ennalta kutsuvasta luokasta riippumatta esim. asetetaan käyttöliittymän nappuloille haluttu väri ja teksti automaattisesti. Asetukset tarvitsee säätää vain kerran. 3)kun olioita halutaan laskea, käytöstä poistettuja olioita kierrättää jne. Kierrätys - Konstruktorin kautta ei voi tarjota jo aiemmin luotua oliota -> tehdasmetodin kautta voi 10:03

Strategy Oletetaan että on olemassa joukko erilaisia tapoja ratkaista jokin laskennallinen ongelma Strategy-mallissa kirjoitetaan ensin ratkaisulle yleinen toteutus jossa vaihtoehtoiset kohdat on ulkoistettu muiden luokkien tehtäväksi Vaihtoehtoisille kohdille on kirjoitetaan rajapinta jonka kautta yleinen toteutus käyttää ulkoistettuja osia. voidaan toteuttaa erilaisia ratkaisutapoja jotka toteuttavat k.o. rajapinnan kautta jonkin osan ratkaisua, mutta ei tarvitse kirjoittaa koko koodia Nyt ratkaisutapaa voidaan haluttaessa helposti muuttaa esim. tekstin jakaminen riveihin vaihtelee kielen mukaan esim. alkioiden vertailu keskenään järjestettäessä 10:03

Strategy import java.util.*; public class StrategyExample{ public static void main(string[] args){ Arrays.sort(args, String.CASE_INSENSITIVE_ORDER); for (int i=0; i< args.length; i++) System.out.println(args[i]); } /* Vaihdetaan järjestämisstrategiaksi toisen * merkin mukaan järjestäminen */ Arrays.sort(args, new Comparator(){ public int compare(object one, Object other){ return ((String)one).charAt(1)- ((String)other).charAt(1); } public boolean equals(object other){ return this.equals(other); } } ); System.out.println(); for (int i=0; i< args.length; i++) System.out.println(args[i]); } Tässä esimerkissä järjestämisalgoritmi on kirjoitettu Arraysluokkaan. Ulkoistettu osa algoritmia on vertailu, jonka koodari voi asettaa antamalla haluamansa Comparator-olion. Esimerkissä luodaan Comparator joka järjestää merkkijonot niiden toisen merkin mukaan. 10:03

Template Method Template method toimii muuten kuin Strategy, mutta puuttuvat osat algoritmia on kirjoitettu abstrakteiksi metodeiksi Metodit toteutetaan aliluokassa jonka jälkeen algoritmi on käyttökelpoinen 10:03

Strategy ja Template Method funktioargumenteilla edelliset kaksi suunnittelumallia muistuttavat kovasti funktioargumenttien käyttöä abstraktioiden tekemisessä ehkä se on funktioargumentteihin tottuneelle niin tavallista, ettei tule mieleen tehdä siitä suunnittelumallia? Strategy-idean voi toki yleistää esim. moduuleihin (useita vaihtoehtoista moduulia, joissa on sama rajapinta)

Suunnittelumallit ja uudelleenkäyttö Adapter Mahdollistaa vanhan koodin käyttämisen. Toimii vanhan koodin uutena julkisivuna joka tarjoaa toisentyyppisen ulkoisen rajapinnan, mutta käyttää alla vanhan luokan metodeja Strategy Mahdollistaa saman algoritmikoodin uudelleenkäytön ulkoistamalla eri käyttötarkoituksissa vaihtuvat osat toisiin luokkiin Template Method Kuten yllä, mutta vaihtuvat osat korvataan aliluokissa 10:03