TIE-20200 Ohjelmistojen suunnittelu Luento 8..9: moniperintä 1
Ajankohtaista Harjoitustyön suunnittelusessiot pidetty, työt jatkuvat, välivaiheen esittely seuraavana Viimeinen viikkoharjoituskerta, palataan takaisin ensimmäisen viikon juttuihin
Ohjelmassa tänään Muutama plugin-esimerkki Pientä kirjastokomponenttijatkoa Rajapintojen rajoitteita Moniperintää
Moniperintää Periytymisessä luodaan uusi luokka periyttämällä siihen jonkun toisen luokan ominaisuudet Moniperintä, otetaan ominaisuuksia useammalta luokalta Ideatasolla erittäin yksinkertainen, mutta tekniikkana kiistelty (vaarallinenkin) Siksi ei mukana kaikissa oliokielissä
Moniperinnän ideasta Tavallinen periytyminen aliluokan olio kelpaa aina kantaluokan olioksi(solid: Liskov s substitution principle) Moniperinnässä aliluokka kuuluu kaikkiin kantaluokkiinsa, kelpaa minkä tahansa kantaluokkansa edustajaksi Periaate: Aliluokan olio on aina kaikkien kantaluokkiensa olio
Moniperintä ja ohjelmointikielet Jätetty kokonaan pois osasta kieliä (esim. Smalltalk, tosin smalltalkin tyypistystapa sallii vastaavien useilla luokilla toimivien rakenteiden luomisen) Osassa mukana osittain rajapintojen kautta, Java & C# Voidaan toteuttaa rajapintoja, tarjota erillisiä käyttö- ja kommunikointirajapintoja (normaalin luokkahierarkian ohessa) Ei kuitenkaan toteutuksen periytymistä Jotkut kielet sallivat täysimuotoisen moniperinnän, jättävät ohjelmoijan vastuulle välttyä ongelmilta Toistuvat rakenteet, diamond problem, miten käsitellään, riippuu vähän kielestä
Moniperintäesimerkki C++:lla Luokkahierarkia ja toteutettava rajapinta Kaksi kantaluokkaa, molemmilla omat funktionsa ja jäsenmuuttujansa ominaisuudet ja syntaksi identtisiä normaalin perinnän kanssa. Kaikki näkyvyysalueet jne. toimivat kuten tavallisessa versiossa. Samaa kantaluokkaa ei voi periä suoraan kahdesti (class Kahdesti: public Kantaluokka, public Kantaluokka) Mahdollista välillisesti
Moniperinnän käyttökohteita Rajapintojen yhdistäminen, luokka toteuttaa useita rajapintoja, helppo ilmaista Javan/C#:n ja esim. ohjelmoinnin tekniikat/alkuoliokurssin viitoittama tapa Moniperinnän käyttö suhteellisen mutkatonta, yleensä ongelmatontakin Kahden tai useamman olemassa olevan luokan yhdistäminen Esim. oliokirjastot, sovelluskehykset Luokkien koostaminen valmiista ominaisuuskokoelmista (mixin, flavours, jäätelöbaari-analogia) Ominaisuuksia, myytävä, lainattava Perustuotteita, kirja, peli Yhdistelmät, kirjaston kirja, myytävä peli Laajentaminen/yhdistäminen: rajapinta, jolle useita toteutuksia, peritään valittu toteutus (protokollat, algoritmit, tiedonesitysmuodot)
Moniperinnän vaaroja Yksinkertaisimmillaan: helppo käyttää väärin, helppo rikkoa olioajattelua (tehdään muurahaiskarhuja, otetaan mukaan kasapäin ylimääräistä yhden/muutaman ominaisuuden takia): ruutu&otus-esimerkki Perintää ei voi käyttää siihen, että olio on välillä yhden kantaluokkansa edustaja välillä toisen (esim. opiskelijatyypit, työntekijät) Moniperintää ei voi käyttää ottamaan yksittäistä ominaisuutta, is-a-suhteen on säilyttävä Kirjastonkirja perittynä päiväyksestä ja kirjasta Tekee ohjelman luokkarakenteesta helposti vaikeaselkoisempaa Elinkaaren hallinta voi vaikeutua (Esim. alustuslukija-ikkuna ja alustustiedotrajapinta) Moniperintää kannattaa välttää, jos mahdollista Kuitenkin hyvä & asiallinen käyttökohde, jos aliluokka kuuluu pysyvästi useampaan kantaluokkaan toteuttaen näiden rajapinnat, rajapintojen perintää ja toteuttamista
Moniselitteisyys Saman niminen funktio mahdollista saada kahdelta eri kantaluokalta Esim. kirjastonteos ja Kirja, molemmilla tulostatiedot funktio, mitä kirjastonkirjalla on? tai korttipakan kortti ja graafinen komponentti, perinnällä tehdään käyttöliittymään korttikomponentti. Molemmissa draw-funktiot. C++ ongelma tulee esiin, vaikka parametrityypissä olisi eroa Ratkaisu: sovitaan, että kutsutaan aina ensimmäisenä perintälistalla olevaa funktiota. Onko ok? Moniselitteinen funktiokutsu (amibiguous call), käänösaikainen ilmoitus
Moniselitteisyys C++:n ratkaisu, yritys kutsua useammasta eri kantaluokasta periytynyttä funktiota Moniselitteinen funktiokutsu (amibiguous call), käänösaikainen ilmoitus Usein kantaluokan saman nimiset funktiot tekevät saman tyyppisiä asioita (kuten kirjastonkirjaesimerkissä, toisin kuin korttijutussa) Jos jäsenfunktio virtuaalinen kaikissa kantaluokissa, voidaan kutsua jokaisen toteutusta vuorollaan (+tarvittaessa lisätä omia juttuja) Mitä tapahtuu ei-virtuaalisten funktioiden kanssa? Yleensä moniselitteisyys ei ratkea näin helposti Jos toiminnot keskenään yhteen sopimattomia, moniperityn aliluokan saaminen käyttäytymään kaikkien kantaluokkien kannalta oikein usein mahdotonta
Moniselitteisyys Ratkaisutapoja: kutsutaan kaikkien kantaluokkien toteutusta (kerrotaan nimiavaruus kutsussa) Jos aliluokka ei halua tarjota uutta toteutusta aliluokassa, homma toimii jos jäsenfunktioita ei kutsuta aliluokan tasolla Jos olioita käsitellään aliluokan tasolla, käytetään kuitenkin kantaluokkatason väliaikaisia osoittimia, viitteitä Kerrotaan mitä toteutusta halutaan käyttää (esim. Kirja::), ei välttämättä oliomaisinta Luodaan uudet keskenään erinimiset funktiot, jotka toimivat läpikutsuina kantaluokkaan
Toistuva moniperiytyminen ( Diamond problem ) (Repeated multiple inheritance, toistuva moniperiytyminen, dreaded diamond of death) Teos, KirjastonTeos, Kirja, Kirjastonkirja Esimerkki: GUI, GUI_Object, Rectangle, Clickable, Button Mitä ongelmia tästä saattaa tulla? Mikä on kirjastonkirjan rakenne?
Timanttista moniperintää Vaihtoehto 1: erilliset kantaluokkaosat, otetaan teoksen tiedot kahteen kertaan, erotteleva moniperiytyminen (replicated multiple inheritance) Vaihtoehto 2: yhteinen kantaluokkaosa, otetaan teos vain kertaalleen, virtuaalinen moniperiytyminen (virtual multiple inheritance) tai yhdistävä moniperintä (shared multiple inheritance) Kaksi kantaluokkaosaa, mitä ongelmia voi ilmetä? (kantaluokan nimimuuttuja) Yhteinen kantaluokka kaikilla, mitäs tämän kanssa? (rakentaminen)
Timanttista moniperintää Erotteleva moniperintä: Sama muuttuja kahteen kertaan, kahdesta eri suunnasta muutos, samalla muuttujalla kaksi eri arvoa (käytetään toisesta perittyä muuttamaan, toisen palvelua tulostamaan tietoja muutos ei näy) Kantaluokkaosoitin mahdoton, ei voida tietää kumpaan olio-osaan halutaan osoittaa/viitata Virtuaaliversio: Sallitaan erillisellä avainsanalla kantaluokan jakaminen (täytyy tehdä kaikissa luokissa joista ollaan perimässä) class Kirja : public virtual Teos // Tai virtual public... Tämän jälkeen moniperinnässä kaikki samasta kantaluokasta perityt luokat jakavat saman kantaluokan Rakentaminen, yksi olio voidaan rakentaa vain kertaalleen Rakentajakutsu tehdään moniperityssä luokassa suoraan yhteiselle kantaluokkatasolle, tämän jälkeen kutsutaan normaalisti kantaluokkien rakentajia Kääntäjä jättää kutsumatta näissä jo kertaalleen kutsuttua rakentaa
C++:n rajapintaluokat & moniperintä Kielessä ei erillistä rajapinnan tai abstraktin kantaluokan käsitettä Miten koodari voi vaikuttaa asiaan? Rakentajat purkajat huomioitava (tällä kertaa automaatiosta on iloa) Kantaluokalle kutsutaan automaattisesti oletusrakentajaa, jos kutsua ei itse määrittele Luokille tuotetaan automaattisesti oletusrakentaja, jos rakentajia ei määritä Purkajan oltava virtuaalinen, sille pitää olla toteutus, tyhjä toteutus pelkälle rajapinnalle hyvä pistää otsikkotiedostoon (ei turhaa toteutustiedostoa, kun kyseessä rajapinnan C++-vastine) Rajapintaluokkien yhdistäminen Ei toimi jälkikäteen koosteena tai kategorisointina (ei voi luoda uutta kahden rajapinnan yhdistelmää jonka alle kaikki nämä rajapinnat toteuttavat luokat automaattisesti kuuluisivat) Täytyy periä aliluokat rajapintayhdistelmistä (luokkahierarkia näyttää rumemmalta, mutta semanttisesti oikea tapa)
Qt ja moniperintä Koitetaan tehdä tapahtumankäsittelijärajapinta Peritään Qobjectista, saadaan mukaan eventit ja slotit Tehdään oma ikkuna, jonka halutaan kuuntelevan tapahtumia Miten toteutus?
Qobjectista ja moniperintä Ei sallita moniperintää Qobjectista käyttäjä ei voi tehdä samaa edes qobjectista perityn abstraktin luokan avulla Moniperinnässä Qobjectin (tai siitä perityn luokan) oltava ensimmäisenä listassa class JokuLuokka: public QObject, public JokuMuuLuokka Virtuaalinen perintä ei ole sallittua Qobjecteista asiaan liittyvää lisäinfoa: (http://qt-project.org/doc/qt-5.0/qtdoc/moc.html) Samankaltaiset rajoitteet/tilanteet mahdollisia myös muita kirjastoja käytettäessä Moniperinnän kanssa kannattaa olla varovainen, tarjolla kryptisiä virheilmoituksia jos suunnitteluperiaatteita rikkoo (C++-kääntäjän päälle tarvitaan laajennoksia, jos rajoituksia jne. halutaan käyttää)
Yhteenveto Moniperinnän kanssa kannattaa olla tarkkana Ennen kuin innostuu puljaamaan moniselitteisyyden jne. kanssa, kannattaa miettiä ohjelman rakennetta vielä kerran Kirjastot ja rajapinnan muuttaminen, kannattaa välttää jos mahdollista Rajapinnan laajentaminen, uusien palveluiden tarjoaminen Toiminnallisuuden korjaaminen TIE-20200 Samuel Lahtinen 19