Uuden tekniikan käyttöönotto on aina haastavaa ja mielenkiin-toista, mutta usein myös riskialtis-ta. Tämä pätee myös siihen "suureen harppaukseen", joka tapahtuu oliomaailmaan astuttaes-sa. Olen saanut seurata kyseistä prosessia muutaman kerran: ensin oman yrityksemme sisällä ja myöhemmin opastaessani asiak-kaitamme olioiden pariin.
Siirryimme Dycomissa olio-menetelmien käyttäjiksi 90-luvun alussa samalla kun merkkipohjai-set käyttöliittymät vaihtuivat graafisiksi. Olio-ohjelmointi GUI-luokkakirjastoilla tuntui huomat-tavasti tehokkaammalta ja miellyt-tävämmältä kuin Windows API:n ja C-kielen käyttö. C-kieli oli ol-lut siihen saakka tärkein työka-lumme, joten emme kovin vaka-vasti pohtineet muiden oliokielien kuin C++ käyttämistä (Visual Basic tai SQL-Windows tyyppiset kehittimet eivät tulleet kysymyk-seen mm. suorituskykyvaatimus-ten takia).
C-kielen kokenut käyttäjä oppii varsin helposti C++ syn-taksin, mutta se ei vielä riitä te-kemään olio-ohjelmoijaa. Kun itse perehdyin C++ kieleen 80-luvun loppupuolella, en tuolloin ollut sisäistänyt oliokeskeistä ajattelumallia, vaan hahmotin asiat erillisinä tietorakenteina ja toimintoina. Niinpä en myöskään suuresti ihastunut C++ kieleen. Olihan periytyminen mielenkiin-toinen konsepti, enkapsulointi siistiä ja näppärää sekä useita C-kielen heikkouksia oli poistettu, mutta entäs sitten?
Vasta myöhemmin, kun olin kahlannut läpi joitakin oliomallin-nusta käsitteleviä kirjoja ja läjä-päin lehtiartikkeleita olioista yleensä, alkoivat palaset asettua kohdalleen. Sulateltuani tämän oliosivistävän tietopaketin palasin olio-ohjelmoinnin pariin ja yllä-tyksekseni huomasin näkeväni asiat uudelta kannalta ja myös C++ kielen olio-ominaisuuksille alkoi löytyä käyttöä toden teolla. Oliot eivät avaudu pelkällä oh-jelmointikielen opiskelulla, vaan oliomenetelmien kantavat ideat on ensin omaksuttava.
Näistä henkilökohtaisista ko-kemuksista viisastuneina aloitim-me oliokoulutuksen yritykses-sämme perehtymällä ensin olio-ideologiaan ja vasta sitten C++ kieleen ja oliomallinnukseen.
Jälkeenpäin on helppo todeta, että oliometodologian kouluttami-seen olisi pitänyt panostaa huo-mattavasti enemmän, koska vain harvasta ATK-ammattilaisesta tulee olioajattelija kertaheitolla. Toisaalta pelkästä teoreettisesta koulutuksesta ei ole iloa, jos op-peja ei pääse heti soveltamaan käytännössä, koska olioiden "ahaa"-elämys syntyy yleensä vain tekemällä, ei pohtimalla.
Parhaisiin tuloksiin päästään-kin, jos kussakin oliomenetelmiin siirtyvässä työryhmässä on yksi jo olioihin syvällisemmin perehtynyt henkilö, joka pystyy jakamaan tietämystään ja toimimaan tutorina muille.
Usein ensimmäisissä oliomene-telmillä toteutetuissa projekteissa käytetään C++/C hybridiohjel-mointia jo siitäkin syystä, että kaikista tarvittavista liityntäraja-pinnoista ei ole saatavissa luok-kakirjastoja ja omien luokkakir-jastojen tekemiseen ei ole riittä-västi aikaa.
C-kirjastojen käyttömahdolli-suus on periaatteessa hyvä asia, mutta kahden erilaisen ohjel-mointiparadigman rinnakkaiskäyt-tö voi johtaa siihen, että aloitte-leva olio-ohjelmoija lipsuu muu-toinkin takaisin vanhoille, "huonoille" tavoille. Yksi tällai-sista regressioilmiöistä on ns. editoriperimä eli kokonaisten koodimodulien kopiointi ja mo-difiointi sen sijaan, että käytet-täisiin periyttämistä ja ohjelmoi-taisiin vain poikkeavat osat.
Ohjelmakoodin uudelleenkäy-tettävyys paranee kyllä yrityksen omien luokkakirjastojen avulla, mutta ilman selkeää kirjastointi-politiikkaa ja versionhallintajär-jestelmää siitä ei saada täyttä hyötyä.
Olioiden tunnistaminen ja op-timaalisen luokkarakenteen suunnittelu ei ole triviaalia. Onneksi tämä ongelma on tiedostettu laa-jemmaltikin ja tarkoitukseen on kehitetty useita erilaisia olioana-lyysi ja -suunnittelumenetelmiä - itse asiassa niitä tuntuu olevan turhankin monta.
Tilanne voi muuttua jatkossa, koska alan johtavat gurut Grady Bootch, James Rumbaugh ja Ivar Jacobsen näyttävät löytäneet yh-teisen sävelen ja kehittelevät uutta menetelmäpakettia. Sen valmis-tumista odotellessamme olemme käyttäneet Rumbaughin OMT-menetelmää (Object Modeling Technique). Perehdyimme mene-telmään käymällä läpi Rum-baughin OMT-kirjan yrityksen sisäisessä viikottaisessa opinto-piirissä.
OMT on suhteellisen helposti omaksuttava tekniikka ja olio-kaavioissa käytetty notaatio on hyvin tutun näköinen kaikille tie-tokantoja suunnitelleille.
OMT-työkaluja on markkinoil-la muutamia (esim. OMTool, ko-timainen Prosa/om), me pää-dyimme Select OMT Toolkit-ohjelmistoon, jossa on koodigene-raattorin lisäksi lisäksi miellyttävä "reverse engineering"-piirre, eli C++ koodiin suoraan tehdyt muutokset saadaan automaattisesti tuotua OMT-kaavioihin.
Oliomenetelmät ovat viime vuosina yleistyneet sellaisella vauhdilla ja laajuudella, että voi-taneen oikeutetusti puhua olio-huumasta. Oliohuuman negatiivi-nen puoli (oliohysteria?) näkyy siinä, että lähes mitä tahansa tuo-tetta, joka edes etäisesti haiskah-taa olioilta, mainostetaan täysi-verisenä oliovälineenä eli kehitys-työkalujen valinnassa saa olla tarkkana.
Vaikka oliomenetelmiä sinänsä voidaan pitää jo koeteltuina ja hyväksi todettuina, on alan työ-välineohjelmistojen kehitys jopa rasittavan nopeaa eli vähintään uusi ohjelmaversio kerran vuo-dessa. Projektityön kannalta uudet välineet ovat aina riskitekijä ja aiheuttavat lisäksi jatkuvan koulu-tustarpeen.
Oliomenetelmistä saatava hyöty on kuitenkin selkeästi suurempi kuin niistä aiheutuvat hankaluu-det. Käyttöönoton alkuvaiheessa tuottavuus voi tosin väliaikaisesti jopa laskea, mutta tilanne korjau-tuu kun olioita opitaan käyttä-mään oikein.
Oliomenetelmillä toteutettujen ohjelmistojen ylläpidettävyys ja laatu on yleensä huomattavasti parempi kuin perinteisillä mene-telmillä tuotetuilla vastaavilla oh-jelmistoilla. Koska oliomenetel-mien käyttö tuottaa laadukkaam-pia ohjelmistoja, kehitystyössä kuluu vähemmän aikaa turhautta-vaan virheiden etsiskelyyn ja tämä heijastuu myös kehityshenkilö-kunnan työtyytyväisyyteen.
Karrikoidusti voidaankin sa-noa, että olio-ohjelmoija on on-nellisempi ohjelmoija kuin perin-teisiä menetelmiä käyttävä kolleegansa.
Yrjö Toiviainen