Ohjelmoinnin peruskurssien laaja oppimäärä, kevät Luento 2: Ohjelman suunnittelua, miten oliot toimivat Riku Saikkonen (osa kalvoista on suoraan ei-laajan kurssin luennoista) 21. 1. 2013
Sisältö 1 Suunnittelua: top-down- ja bottom-up-menetelmät 2 Suunnittelua: Model-View-Controller -malli 3 Miten oliot ja metodikutsut toimivat?
(ei-laajan kurssin kalvo: luento 2 sivu 4) 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 11:31
(ei-laajan kurssin kalvo: luento 2 sivu 5) Top-Down Suunnittelussa määritellään järjestelmien ulkoiset rajapinnat ennen niiden toteutusta Toteutusvaiheessa 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 11: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
(ei-laajan kurssin kalvo: luento 2 sivu 6) 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 11: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
(ei-laajan kurssin kalvo: luento 2 sivu 7) 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 toteutukseen koodin uudelleenkäyttö helpottuu Bottom-up toteutuksella päästään (yksikkö)testaamaan koodin osaset heti niiden valmistuessa 11: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 jotkut vähemmän
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ä
Sisältö 1 Suunnittelua: top-down- ja bottom-up-menetelmät 2 Suunnittelua: Model-View-Controller -malli 3 Miten oliot ja metodikutsut toimivat?
(ei-laajan kurssin kalvo: luento 2 sivu 8) Sunnittelu 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 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. Käyttöliittymä hakee logiikalta ruudulla näyttämänsä tavaran. GUI ohjaa, pyytää tietoa Aivot 11:31
(ei-laajan kurssin kalvo: luento 2 sivu 10) Suunnittelu Model-View-Controller Tämä suunnittelumalli menee vielä askeleen pidemmälle, erottaen GUI:n (Controller) osat jotka muuttavat mallia (Model) ja osat jotka vain esittävät mallin sisältämää tietoa(view) Controller Tiedot päivittyivät ohjaus muutoskäskyt View Esitettävän datan kysely Tiedot päivittyivät, käy kysymässä Model 11: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 (sekä käyttöliittymästä että automaattisesti esim. laskemalla) ei kerro näkymälle datasta (näkymä hakee ne mallilta) käytännössä MVC:tä käytetään harvoin täsmälleen näin: useimmiten jollain tilanteeseen sopivalla tavalla muokattuna
Käytännön esimerkki ConvertAll on pieni GUI-ohjelma yksikkömuunnoksiin http://convertall.bellz.org/download.html katsotaan sen asetuksien muokkaamista (Options-ikkunaa) voit ensiksi miettiä top-down-tyyliin miten tekisit tämän osan ohjelmasta: noin 10 yksinkertaista asetusta (esim. taustaväri, luvuissa näytettävien desimaalien määrä) käyttöliittymä niiden näyttämiseen ja muuttamiseen yksi kerrallaan kaikki talletetaan automaattisesti tekstitiedostoon
Käytännön esimerkki ConvertAll on pieni GUI-ohjelma yksikkömuunnoksiin http://convertall.bellz.org/download.html katsotaan sen asetuksien muokkaamista (Options-ikkunaa) voit ensiksi miettiä top-down-tyyliin miten tekisit tämän osan ohjelmasta: noin 10 yksinkertaista asetusta (esim. taustaväri, luvuissa näytettävien desimaalien määrä) käyttöliittymä niiden näyttämiseen ja muuttamiseen yksi kerrallaan kaikki talletetaan automaattisesti tekstitiedostoon MVC-malli sopii tähän esimerkkiin osittain: Model: source/option.py luokka Option (sekä oletusarvot source/optiondefaults.py) View: lähinnä source/optiondlg.py sekä source/convertdlg.py metodi changeoptions Controller: lähinnä source/optiondlg.py:n updatedata-metodit (toteutus olisi todennäköisesti lähempänä puhdasta MVC:tä, jos olisi tarpeen olla useita eri View-näkymiä samaan dataan)
Sisältö 1 Suunnittelua: top-down- ja bottom-up-menetelmät 2 Suunnittelua: Model-View-Controller -malli 3 Miten oliot ja metodikutsut toimivat?
Minkä luokan metodia kutsutaan? Python-esimerkki import math class Point(object): def init (self, x, y): self.x = x self.y = y def dist(self, point): def square(x): return x*x return math.sqrt(square(self.x - point.x) + square(self.x - point.x)) def pprint(self): print 'Point at '+str(self.x)+', '+str(self.y) class ColoredPoint(Point): def init (self, x, y, color): Point. init (self, x, y) # tai: super(coloredpoint, self). init (x, y) self.color = color def pprint(self): print 'Colored point at '+str(self.x)+', '+str(self.y)+\ ' colored '+self.color p1 = Point(5, 8) p2 = ColoredPoint(2, 3, 'black') p1.pprint() # "Point at 5, 8" p2.pprint() # "Colored point at 2, 3 colored black" print p1.dist(p2) # 4.24264068712 print p2.dist(p1) # 4.24264068712 point.py
Dynaaminen metodinvalinta Jatkoa edelliseen esimerkkiin def printpoint(p): print "The point is:" p.pprint() printpoint(p1) printpoint(p2) printpoint(p2) kutsuu aliluokan ColoredPoint metodia koska p2-muuttuja osoittaa tämän luokan olioon mutta printpoint-funktio ei etukäteen tiedä, mitä metodia p.pprint() kutsuu (riippuu p:n arvosta) kutsuttava metodi valitaan siis dynaamisesti eli vasta ajon aikana (dynamic dispatch, dynamic method lookup) eli ajon aikana joudutaan tekemään hiukan ylimääräistä työtä proseduurikutsuun verrattuna pohjimmiltaan juuri tämä ominaisuus määrittelee, mikä on olio-ohjelmointikieli kieli tukee olio-ohjelmointia, jos se tarjoaa mahdollisuuden tehdä dynaamista metodinvalintaa
Staattinen metodinvalinta toinen vaihtoehto olisi valita metodi staattisesti esim. olion käännösaikaisen tyypin tai jonkun muun koodissa esiintyvän tyyppinimen mukaan Pythonissa esim. yliluokan konstruktorin kutsu Point. init (self, x, y) (luokan nimi annetaan koodissa) samoin Javan ja Pythonin super tekee staattisen metodinvalinnan (super-kutsun sisältävän luokan isäluokka) ja C++:n ei-virtuaaliset metodit (joita kutsutaan muuttujan käännösaikaisen tyypin mukaan) entä jos metodi valittaisiin aina staattisesti? kieli ei tukisi olio-ohjelmointia (vrt. edellinen kalvo) monet moduulijärjestelmät toimivat periaatteessa näin (esim. ML) koska metodi on tiedossa käännösaikana, metodinvalinnan voisi toteuttaa esikäsittelemällä koodia (automaattisesti tai käsin): staattisesti kutsuttava metodi käyttäytyy kuten globaali funktio monissa kielissä on molemmat metodikutsutavat (esim. C++:ssa tapa valitaan metodia määriteltäessä, Pythonissa kutsussa)
Mitä oliosta on tallessa muistissa? ajon aikana luokat ja metodit ovat jo tiedossa: ne on luotu käännösaikana tai luokkia määritellessä sen sijaan kenttien arvot ovat jokaiselle oliolle yksilöllisiä ajon aikana jokaisesta oliosta on tallessa: kenttien arvot viittaus luokan tiedot (mm. metodit) sisältävään tietorakenteeseen mikä sitten on metodi? proseduuri, joka saa implisiittisenä argumenttina olion, jonka kautta metodia kutsuttiin (Javassa tästä tulee this; Pythonin self näkyy eksplisiittisesti metodin määritelmässä, muttei näy kutsussa) metodista on siis (esim. Javassa) muistissa vain koodi vrt. proseduuri Scheme-tulkissa: koodi ja määrittely-ympäristö (sisäkkäisten luokkien tukemiseen voisi tarvita myös määrittely-ympäristöä) monissa kielissä metodia ei kuitenkaan voi käyttää esim. funktioargumenttina (Pythonissa voi)
Miksi perintä on tärkeää? miksi olio-ohjelmoinnissa puhutaan niin paljon juuri perinnästä? sen käyttäminen on monimutkaista... vaikka olio-ohjelmoinnissa on paljon muutakin, perinnän tuki erottaa olio-ohjelmointikielet muista kielistä usein monimutkaisemmat olio-ohjelmoinnin rakenteet (esim. suunnittelumallit) tarvitsevat perintää ilmankin perintää voi tehdä paljon olio-ohjelmointia esim. SICPin message passing -olioesimerkit moduuli joka käsittelee tiettyä tietorakennetta olio joten olioihin pohjautuvaa suunnittelua voi tehdä myös muissa kuin oliokielissä oliosuunnittelun perusidea: mallinnetaan ratkaistava ongelma itsenäisinä olioina, jotka kommunikoivat viesteillä toteutuksen ei tarvitse olla oikea olio näin vältetään perinnän aiheuttamia ongelmia, mutta menetetään osa abstraktiomahdollisuuksista jotkut eivät kuitenkaan pidä tätä varsinaisena olio-ohjelmointina