Minkä tyylinen oppija olen? Minkälainen tapa oppia ohjelmointia sopii itselleni?

Toinen kymmenen tärkeyspisteen otsikko yllä. Varsinkin ensimmäinen kysymys on jokaiselle opiskelijalle ja jopa ihmiselle tärkeä asia, jonka keksimiseen voi mennä kauankin aikaa. Jälkimmäinen kysymys tarkentaa ensimmäistä, joten rajaan tämän kirjoituksen aiheen ohjelmoinnin opiskeluun.

Olen aina ollut hirveän laiska opiskelemaan mitään itselleni vähänkään tylsää tai vastenmielistä. Ohjelmointi lukeutuu molempiin kategorioihin. Siksi kurssilla olevat teoriatehtävät ovat olleet tuskallisia tehdä, vaikka niistä läpi selvisinkin. Itse ohjelmointi menee ihan hyvin, ja koen oppivani sitä nopeimmin kokeilemalla. Kurssikirjaa en ostanut, vaan lainasin kirjastosta, mutta se maksoi minulle 11 euroa, koska kaksi kertaa unohdin uusia lainan ja sainpa tilille hetkeksi lainauskiellonkin.

Itse asioista selvää ottaminen on raskasta ja aikaavievää. Varsinkin graafisiin käyttöliittymiin liittyvät asiat ovat tämän vuoksi olleet minulle raskaita. Sadat valmiit luokat ja niiden tuhannet metodit ja niistä sopivimpien etsiminen ja löytäminen ovat varmasti alkukynnyksen ylittymisen jälkeen käteviä käyttää, mutta minulle opettelun henkinen muuri on liian korkea ylitettäväksi – tai ainakin on ollut tähän asti.

Pidän vihjeiden perusteella tekemisestä, ja siksi olenkin aina nauttinut Studio1-kurssin ohjelmointiosan tehtäväkierroksista, joissa kerrotaan, missä järjestyksessä asiat kannattaa tehdä ja miltä niiden tulee näyttää. Jopa käytännön toteutukseen saa vähän apua, tai ainakin on kerrottu, mistä aiheeseen liittyvää teoriaa kannattaa opiskella. Varsinkin tänä vuonna vihjeet olivat tehtävänantojen välittömässä yhteydessä, mikä auttoi omaa keskittymistä ja opiskelua paljon. Minulle yhdessä tekeminen on aina ollut mieluisaa, mutta Studio1-kurssin suuresta yhteisöllisyydestä huolimatta ohjelmoimisesta on jäänyt vähän negatiivinen kuva “yksinäisen puuhasteluna”. Ehkä siksikään ohjelmointi ei ole minun lempitekemistäni, etten usko koskaan haluavani tehdä tai suunnitella ohjelmia käytännön tasolla.

OLOsessioissa on hyvä idea, pienryhmäoppiminen ja asioiden pureskelu yhdessä, mutta sen toteutus on mielestäni itselleni sopimaton. Olisi hyvä, jos tilaisuudessa olisi puheenjohtajana asioista eniten tietävä, jolta olisi helppo kysyä mitä tahansa mieleen tulevaa ongelmaa. Tällä hetkellä OLOsessiot ovat ryhmäläisten yhteistä pohtimista asioista, joista assistentit jo valmiiksi tietävät erittäin paljon mutta ovat taka-alalla. Itselleni voisi sopia paremmin suorempi “tässä aihe, lähdetään purkamaan tällä tavalla” -lähestyminen kuin Post-it -laput, tussit ja seitsemän tuskaista askelta. Myös se, että tapaamisen puheenjohtajaksi joutuu joku tehtävään sopimaton tai sitä haluamaton henkilö, on mielestäni aivan turhaa. Jos tapaamisen perusideassa on mielestäni joku virhe, asioiden omaksuminen ja niistä keskusteleminen vaikeutuvat minulle henkilökohtaisesti aika paljon. Itselleni sopisi ehkä parhaiten, että asiat käytäisiin läpi yhdessä ja pienryhmätasolla mistä tahansa asiasta voisi herättää keskustelua, jos ei ymmärrä tai haluaa lisäselvitystä. Keskusteluun voisivat osallistua kaikki, mutta sitä johtaisivat assistentit käytännönläheisin esimerkein. Tähän suuntaan ollaan ymmärtääkseni oltu muutama viime vuosi siirtymässäkin.

Tentissä huomasin, että ensimmäisten kahden osan teoriat eivät olleet ollenkaan tarvittavalla tavalla hallussa, mutta se oli odotettavaakin laiskasta lukemisesta johtuen. Tämä kaikki heijastui myös ohjelmointitehtäviin, joissa kesti aina aikansa opiskella tulevaa teoriaa ennen kuin pääsi kunnolla vauhtiin. Tekemällä teoriatehtävät kunnolla olisi ehkä säästänyt joissain ohjelmointiharjoitusten asioissa, mutta oppinut ehkä paljon sellaistakin, jota ohjelmointiharjoituksissa ei suoranaisesti tarvinnut. Minulle hieman vastenmielisen aihepiirin asiat eivät motivoineet tarpeeksi opettelemaan kaikkia asioita kunnolla.

Itselleni siis ohjelmoinnin opiskeluun sopivat parhaiten yhdessä tekeminen ja avoin keskustelu asioista enemmän tietävien kanssa, sekä käytännön kokeileminen ja itse tekeminen. Asioiden opettelu ennakkoon oppikirjoista tai nettiartikkeleista ei välttämättä ole se omin juttu, vaikka se varmasti paljon olisi oppimista helpottanutkin.

-Henri

Miten kurssia voisi parantaa?

Aah.. The mother of all questions. Not. Mutta kuitenkin tärkeä asia.

Koska uusien opiskelijoiden ensimmäinen syksy perinteisesti kuluu lähes kokonaisuudessaan tietokoneen äärellä ohjelmointia opetellessa, opetusajan maksimaalinen hyödyntäminen on mielestäni erittäin oleellinen asia. Olin itse Studio1-kurssilla ensimmäistä kertaa jo kaksi vuotta sitten. Kurssi on mielestäni muuttunut aika paljonkin silloisesta. Me emme tehneet ollenkaan tenttiä, blogin paikalla oli jokaisen henkilökohtainen portfolio, ohjelmointitehtäviä oli nykyisen kuuden sijasta viisi, bottiturnausta ei ollut, kumpaakaan turnausta ei arvosteltu, OLOsessioiden opetuksen taso oli heikompaa ja ainakaan muistaakseni projektityölle ei oltu varattu ohjattua opetusta joululoman aikana.

Lähes kaikki uudistukset ovat mielestäni parannuksia menneeseen, mutta käytännön pikkuasioita voisi viilata. Jos ohjelmointitehtävien keskiarvo on melkein neljä, mutta tentistä jaetaan sääliykkösiä, pitää mielestäni miettiä. Ovatko vaatimukset linjassa ohjelmointitehtävien vaatimusten kanssa, vai onko ohjelmointitehtäviä tehty yhteistyössä niiden muutamien asiat oikeasti parhaiten hallinneiden kanssa? Jos ohjelmointi- ja teoriatehtävien keskiarvot kohoavat lähelle nelosta, mutta tenteissä on havaittavissa selkeä kahtiajako osaajiin ja osaamattomiin, on joku pielessä.

Mielestäni tentin osuutta kurssin arvostelusta kannattaisi nostaa korkeammaksi, ja vaikeammin arvosteltavissa olevien asioiden, kuten näiden blogikirjoitusten sekä robo- ja bottiturnauksen arvostelun osuutta pienentää tai poistaa kokonaan. Tentin arvosanan tulisi mielestäni olla suoremmin linjassa koko kurssin arvosanan kanssa, koska samaa menetelmää käytetään muutenkin yleisesti koulumme kursseilla. Toisaalta ennen kurssia arvottujen ryhmien töiden oikeudenmukainen arvosteleminen on ongelmallista, koska riittää, että ryhmässä on yksi ohjelmointimestari, joka tekee tehtävän valmiiksi ja muut hoitavat dokumentointiosuuden. Jos ryhmään ei ohjelmointimestaria satu, on se huonompi juttu.

Kun mietin, kumpi oli parempi idea, tehdä portfolio vai kirjoittaa yhteistä blogia, en päässyt selvään lopputulokseen. Portfoliota tehdessä kenenkään ei tarvitsisi vaivata päätään sillä, miten muiden ryhmäläisten panos vaikuttaa omaan kurssiarvosanaan, mutta toisaalta olen ymmärtänyt, että ohjelmointi suuremmassa mittakaavassa yleensä on ryhmätyötä, jossa ryhmällä on yhteisiä tavoitteita ja vastuita. Toisaalta portfoliota tehdessä saa harjoitusta html:n käytöstä, saa itse päättää, minkälainen toteutuksesta tulee ja pääsee ehkä enemmän toteuttamaan itseään muuten kuin verbaalisesti. Blogissa on helppo seurata, minkälaisissa tunnelmissa muut ryhmäläiset kurssia suorittavat, ja kertoa omia mielipiteitään muille. Yhteisessä vastuussa on taas arvosteluongelmansa, vaikka blogi arvioidaan osaksi henkilökohtaisestikin. Tässä ryhmädynamiikkaa testataan toki eri tavalla kuin robo- ja bottiturnauksissa, sillä ei riitä, että yksi kirjoittajamestari hoitaa homman, kun muut katselevat vieressä, vaan ainakin melkein koko ryhmän panosta tarvitaan blogin onnistumiseen. Tämän vuoksi blogi sopii ryhmässä arvosteltavaksi kokonaisuudeksi mielestäni huomattavasti robo- ja bottiturnausta paremmin.

Ohjelmointitehtävien lisääminen yhdellä ei uskoakseni vaikuttanut kovin oleellisesti kurssin kokonaistyöläyteen, mutta graafisten käyttöliittymien osuuden lisääminen yhdestä viidesosasta yhteen kolmasosaan kurssin ohjelmointitehtävien sisällöstä on mielestäni huippu-uudistus! Vieläkin koen itselleni henkiseksi esteeksi graafisten käyttöliittymien tekemisen, sillä hyppäys valmiiden luokkien hyödyntämisen maailmaan tuntuu liian suurelta.

OLOsessiot, nuo ainaiset henkilökohtaiset riippakiveni, ovat minun nähdäkseni edelleen kurssin “löysin” osa. Jos nuo kymmenisen kaksoistuntia vaihdettaisiin vaikka yhdessä ohjelmoimiseksi niin, että edelleen pienryhmissä yksi assari kerrallaan tekisi konkreettisia mallitehtäviä yhdessä ryhmän kanssa, luulen, että saavutettava hyöty olisi moninkertainen verrattuna nykyiseen. Saataisiin kaksinkertainen määrä opetusta ja konkreettisia esimerkkejä siitä, miten kannattaa tehdä ja miten ei, kun nykyään sessioissa istutaan tuppisuina ja kirjoitellaan post-it -lapuille mielestäni aivan turhanpäiväisiä asioita, kun konkreettinen oppiminen jää todella vähäiseksi.

Kokonaisuudessaan kurssi on mainio paketti, ja varsinkin ohjelmointitehtävät ovat erittäin mielenkiintoisia. Edellä pohdiskelemillani asioilla voisi ehkä viilata toimivamman ja tehokkaamman ratkaisun, mutta varmasti käytännön muutoksia tarvitsisi miettiä tarkkaan ennen toteuttamista.

-Henri

Mitä hyötyä on siitä, että metodeilla on argumentteja?

Metodien argumentit, tuttavallisemmin (ainakin minulle) parametrit, esiintyivät ohjelmointitehtävissämme alusta alkaen. Kesti hetken aikaa ennen kuin ymmärsin niiden syvällisemmän merkityksen. Tehtävissä sanottiin, että laita tämä metodi ottamaan parametrinaan kokonaislukumuuttuja ja helppoahan se oli sokeasti totella ohjeita. Ensimmäisen harkan aikana opin jo ymmärtämään, että parametreilla pystytään vaikuttamaan metodin palatusarvoon, mutta sen syvällisemmin en asiaa pohtinut.

Tässä vaiheessa minulle oli vielä täysin hämäränpeitossa, mitä pääohjelmametodin String[] args oikein tarkoittaa. Olin aina vain kirjoittanut sen sulkujen sisälle kiltisti vailla sen kummempaa ymmärrystä sen tarkoitusperistä. Neljännessä Javatehtävässä vihdoinkin käsiteltiin sitä. Kyse onkin komentoriviparametrista. Omassa ohjelmassamme komentoriviparametreiksi määritettiin nimi ja nopeus. Käynnistettäessä ohjelma kysyi näitä määritettyjä arvoja ja tallensi ne muistiin. Näin ohjelman käyttäjä sai määritellä aluksi oman nimensä ajaessaan ohjelmaa.

Main-metodi on kuitenkin poikkeustapaus. Kurssin edetessä oppia kertyi ja metodien parametritkin tulivat tutummaksi ja tutummaksi.  Ne muodostuivat itsestäänselvyyksiksi. Suuri askel oli kun osasi itse määrittää metodille tilanteeseen sopivat parametrit. Varsinkin lopputehtävissä tuli pelailtua konstruktorien parametrien kanssa, kun monen luokan piti tuntea moni muu luokka ja parametrejä kertyi lukuisia tehtävän edetessä.

Parametreilla voi siis vaikuttaa metodin palautusarvoon. Kuvitellaan, että metodi ottaa parametrinaan boolean-muuttujan ja metodin sisällä määritellään erilaiset palautusarvot sekä true-arvolle, että false-arvolle. Nyt metodi palauttaa arvon, joka riippuu annetun parametrin totuusarvosta. Tässä tulee juuri ilmi parametrien eli argumenttien hyödyllisuus – ei tarvitse tehdä jokaiselle tilanteelle omaa metodiansa.

-Olli

Miten ajatukseni ohjelmoinnista on muuttunut kurssin aikana?

Iki-ihana kurssimme (näin pystyn jo melkein ajattelemaan näin kurssin viimemetreillä) Studio1 starttasi syyskuun puolivälin tienoilla. Elokuun lopussa saimme kotiin kirjeen mukana esitteen, jonka tarkoitus oli antaa hieman esimakua tulevasta syksystä ja Java-ohjelmoinnista. Minulle tämä ei kuitenkaan sanonut yhtään mitään. Ajatus koko hommasta oli vain että “TÄH, koodausta, no okei sitten..”. Pahaa-aavistamattomat phuksit kerääntyivät TUAS-talon luentosaliin aloitusluennolle. Tällöin kuulimme myös ensikertaa Kalakirjasta ja tajusimme, mitä koko syksymme tulee tästedes olemaan.

Ensimmäinen harjoitus sujui vielä hyvin tietämättömänä mitään itse koodauksesta tai siitä, mihin kaikkeen sitä voi hyödyntää. Yhteys Java-peleihin oli erittäin häilyvänä mielessä. Jotenkin Java ei ohjelmointikielenä, tai ylipäänsä ohjelmointi, sanonut minulle mitään! Mielestäni oli kummallista kirjoittaa kymmenen riviä tekstiä, jotta saisi tulostettua tekstin “Hello World!” Miksei saman tien vain kirjoittaisi kyseistä lausetta?

En lähtenyt tähän hommaan riittävän hyvällä asenteella. En ajatellut ohjelmointia mitenkään helppona hommana, mutten toisaalta sellaisenakaan, mitä haluaisin tai ylipäänsä voisin vielä joskus osata. Kurssin alkuvaiheessa näin pari kurssilla toteutettua projektia, nämä olivat pelejä, enkä ikimaailmassa osannut kuvitellakaan itse tekeväni mitään senkaltaistakaan. Tuossa vaiheessa opetteluni oli lähinnä ohjeen sokeana seuraamista ja assareilta saamien neuvojen mukaan koodin kirjoittamista. Eli sisäistetty asia jäi ehkä kymmeneen prosenttiin tavoitteesta. Jotenkin suljin Javan kokonaan pois kaiken muun tieltä. En ymmärtänyt, miksi jotain tällaista pitää opetella.

Koodaus alkoi synkän harmaalla Emacs-editorilla. En koskaan oppinut käyttämään kaikkia sen ominaisuuksia, sillä hajosin jo copy-pasten aiheuttamaan jumitustilaan. Eclipse helpotti elämääni sekä fyysisesti että henkisesti. Jotkut tuntevat nostalgiaa nyt myöhemmässä vaiheessa käyttäessään Emacsia. Jotenkin en itse koskaan oikein ihastunut Emacsin käyttöön. Eclipsen avulla opin paljon lisää ja paljon hyödyllistä, muunmuassa parametreista ja valmiiden luokkien tarjonnasta. Aloin oikeasti, ehkä jollain tuntemattomalla tasolla, välillä jopa pitämään koodaamisesta.

Vihdoin, kaikista kolmesta ensimmäisestä tehtävästä selvinneenä, neljäs tehtävä toi mukanaan jo jotain ihan konkreettista näkuviin ikuisen puurtamisen jälkeen. Pääsi jo seuraamaan omaa tuotostaan ja pelaamaan “itse tehtyä” peliä. Sikobanin myötä pääsin luomaan oman graafisen käyttöliittymän. Mielenkiinto lisääntyi koko ajan, kun halusi saada lisää toiminnallisuutta, vielä enemmän juttuja näkyviin!

Omaa aikaa ei ollut käytettävissä koodille, eikä se alkuvaiheessa vielä haitannutkaan. Kuitenkin algoritmit olivat monimutkaisia jo alkuvaiheessa ja näin tuntuivat hyvin hyvin hankalilta vielä myöhemminkin. Jälkeenpäin harmittaa kuinka paljon enemmän olisin voinut alkuvaiheessa perusasioista opetella, ja kuinka paljon enemmän nyt osaisin, kuinka hienon projektin olisinkaan voinut saada aikaiseksi.

Projektin voisin sanoa muuttaneen käsitystäni ohjelmoinnista varmasti eniten. Kun ei ollut käytettävissä assareita, joiden hihasta olisi voinut nykäistä epävarmassa tilanteessa, oli vain pakko uskaltaa kokeilla! Omat ratkaisut eivät aluksi tuottaneet onnistunutta lopputulosta läheskään aina, mutta pienetkin onnistumiset kohottivat itsetuntoa ja auttoivat eteenpäin! Projektiini olen lopulta tyytyväinen . Opin yhteensä varmasti enemmän kuin koko kurssin aikana. Opin itse perehtymään virheisiini ja niiden aiheuttajiin sekä ratkaisuihin. Nyt tiesin jo hieman etukäteen jotain siitä, mitä tulee tapahtumaan ohjelmaa ajettaessa. Projektissani käytin tietenkin tuttuja (Javan valmiita)luokkia ja looppeja. For-lauseesta tuli suosikkini ja ArrayList oli esiintynyt jo niin monta kertaa, että ne olivat selvät valinnat, kun mietin eri silmukka- ja kokoelmavaihtoehtoja.

Nyt kun sain projektinikin tehtyä ja sen myötä huomattua, kuinka paljon loppujen lopuksi itseasiassa osaa koodata, (paljon olisi tietysti opeteltavissa vielä, jos haluaisi) on käsitys koko kurssia kohtaan hieman muuttunut. Projektin aikana koodin kirjoittaminen ei tuntunut hirvittävän ylivoimaiselta paria poikkeusta lukuunottamatta. Luulenpa, että asiaan vaikutti eniten juuri se näkyvän tuloksen aikaansaaminen. Helpompi ajatella, keksiä uusia ideoita ja korjata virheitä, kun lopputulos on nähtävissä. Itseluottamus oli myös kova tekijä tässä, oli paljon mukavampi tehdä jotain, kun tiesi, että siinä voi myös onnistua!

Kyllä näin lopuksi on pakko sanoa, että on se kivaa kun sen osaa . Kaverit ja sukulaiset ovat innoissaan pienistäkin ohjelmista, mitä on saanut aikaiseksi. Monta tilausta olen saanut koodattavaksi, mutta katsotaan nyt, avaanko Eclipseä enää tänä vuonna, niin mukava kaveri kun siitä onkaan tullut.

-Meri

Koodieditorit ohjelmoinnin apuna

Tuntuu vähin nurinkuriselta kirjoittaa vielä päätöspuheenvuoron jälkeen, mutta täältä tulee nyt vielä se toinen portfolioessee.

Kurssin aikana tuli käytettyä monenlaisia ohjelmia. Aivan uutta olivat koodieditorit, tai jos nyt vähän hienostuneemmasta ohjelmasta puhutaan, kehitysympäristöt. Ensimmäiset ohjelmointitehtävät tuli paahdettua läpi Xemacsia käyttäen. Xemacs tuntui todella näppärältä ohjelmalta, se pystyi jopa korostamaan tekstiä tuoden suuren avun koodausarkeen.

Liikkui kuitenkin huhuja vielä hurjemmasta sovelluksesta. Eclipse pystyisi näyttämään suoraan virheitä reaaliaikaisesti kääntävällä virtuaalikoneella. Se sisältäisi myös sisäänrakennetun API-hakemiston, jolloin varsinaista Sunin API-sivustoa ei tarvitsisi aivan jatkuvalla syötöllä selailla.

Kokeillessani Eclipseä ensimmäisen kerran olin jonkun verran epäluuloinen: se tuntui vähän monimutkaiselta kaikkine pikkuikkunoineen ja pikanäppäimineen. Epäluulot haihtuivat kuitenkin nopeasti: Eclipse nopeutti ja helpotti koodausurakkaa suuresti. Ei tarvinnut enää leikkiä komentorivin kanssa vaan Eclipse laittoi classit huutamaan hoosiannaa yhdellä hiirenklikkauksella.

Projektin jälkeen Eclipsestä oli tullut jo niin kiinteä osa koodausprosessia, että ihan helpolla en sitä vaihtaisi takaisin XEmacsiin. Toisaalta saattoi olla ihan hyvä asia, että ensimmäiset Java-kotitehtävät tuli tehtyä Xemacsilla. Se pakotti miettimään todella oikeaoppista Java-syntaksia – näin ainakin assareiden mielestä.

Sun Microsystemsillä on myös oma vastineensa Eclipselle: NetIde Javabeans. Tätä ohjelmaa ei tullut koskaan käytettyä (ei ollut varmaan tarpeenkaan).

Käsitekarttojen teossa tuli tutustuttua myös uuteen ohjelmaan – CmapToolsiin. Se oli kaikenkaikkiaan positiivinen yllätys. Käyttöliittymä oli yksinkertainen ja ohjelma teki nättiä, antialiasoitua jälkeä. Tutustuimme myös dialogikarttaohjelmaan, joka jäi vaisuksi tähdenlennoksi Sitä käytettiin ainoastaan yhdessä OLO-sessiossa.

Käytin myös omia grafiikkaohjelmia blogikirjoituksissa ja teoriatehtävien viimeistelyssä. Parhaan lopputuloksen sai usean eri ohjelman parhaita puolia hyödyntämällä.

Syksyn aikana tuli vietettyä (liian) paljon aikaa tietokoneen ääressä. Myös IRC:n käyttö juurtui selkäytimeen. En nyt tiedä onko se kovin hyvä asia…  Laadukkaat ohjelmat auttoivat huomattavasti syksyn urakkaa. Eclipse saa nyt kuitenkin levähtää jossakin syvällä kiintolevyn uumenissa – ainakin hetken.

 

- Teemu

Mitä hyötyä on perinnästä?

Ensimmäisissä ohjelmointitehtävissä tehdyt luokat kuten Esine ja sen aliluokat Arkku ja Kolikkokasa ym. eivät mitenkään kertoneet minulle perimän tarkoituksesta – mitä hyötyä tästä oikein on? Mitä mieleeni ensimmäisenä tuli oli, että onpas hauska kun kytketään jokin luokka toiseen periyttämällä se toisesta luokasta. Onhan se nyt selvää, että kolikkokasa ja arkku voidaan laskea esineiksi. Mitä pidemmälle kurssi eteni, sitä useammin luokan nimen perään kirjoitettiin sana extends ja jokin toinen luokka. Tämä oli mielestäni vain hauskaa ja loi luokkien välille jonkinlaista yhteenkuuluvuuden tunnetta.

Perinnän tarkoituksesta selvisi minulle eniten viidennessä Java-tehtänässä, jossa luotiin Sikoban luokka, joka siis peri JFramen ja sai näin käyttöönsä kaikki JFramen ominaisuudet ja metodit. Koin elämyksen kun joku assareista harjoituksen aikana neuvoi käyttämään this-sanaa JFramen metodeja kutsuttaessa. Ensin näitä päästiin tietysti etsimään JavaAPIsta ja “How to use” -kohta oli äärettömän valaiseva. Tässä vaiheessa tajusin, että tämähän itseasiassa tarkoittaakin sitä, että Sikoban-luokka on JFrame ja olisi sama kuin jos Sikoban-luokka pitäisi sisällään kaikki JFramen metodit. Ja taas tunnelmia: oli vain mahtava fiilis kun ikkuna aukeutui näytölle, ja tällä kertaa ihan itse aiheutettuna!

Jos minun nyt pitäisi selittää tärkeimmät asiat perinnästä, sen hyödyt ja käyttötarkoitukset sun muut siitä mitään tietämättömälle puhuisin varmasti ja luottavaisesti, en epäröisi asiassani. Aloittaisin kertomaan luokista ja niiden aliluokista, jotka “periytetään” näistä yliluokista, ja siitä kuinka aliluokat saavat yliluokkiensa ominaisuudet. Luokalla voi siis olla vain yksi yliluokka, kuten ihmiselläkin vain yksi äiti (isää ei nyt saa ottaa mukaan), mutta monta aliluokkaa, kuten äidillä lapsia. Koetilanteessa joutuisin kuitenkin miettimään sana- ja lausevalintojani, niin selvää perintä kokonaisuudessaan ei minulle vielä ole.

Selittäisin varmasti eläimistä, kissoista ja koirista, ja näiden ilmentymistä eli Mirristä ja Turresta. Luodaan siis luokat Eläin, Kissa ja Koira. Luokat Kissa ja Koira laitetaan perimään luokka Eläin. Eläin-luokan ilmentymät saavat luomisvaiheessa nimen ja painon. Näin on täten myös Kissa ja Koira -luokkien kohdalla. Näille voi kuitenkin antaa nyt jotain uusia ominaisuuksia ja määritellä metodeja, jotka tekevät näiden kahden ilmentymistä eläintä tarkempia ja toisistaan eroavaisia. Koira-luokan ilmentymät voisivat nyt nimen ja painon lisäksi saada ominaisuuden “uskollisuus” ja metodin “hauku”. Kissat taas omiaisuuden “hännän pituus” ja metodin “kehrää”. (Tämähän alkaa kuulostaa jo ensimmäisissä OLO-sessioissa käydyltä keskustelulta tai lähinnä assarin selitykseltä suu auki ja silmät pyöreinä katsoville phukseille).

Mielesstäni perinnän suurin hyöty tulee esille siinä, kun halutaan pitää samantyyliset, mutta kuitenkin erilliset asiat/ilmentymät/jotainihanmuuta(?) erillään, mutta silti kytkettyinä toisiinsa. Luokkien kokoa voidaan pienentää, kun jokaiseen ei tarvitse erikseen kirjoittaa samoja ominaisuuksia ja metodeja. Samalla hahmottuu kokonaisuus paremmin, kun nähdään, mitkä luokista kuuluvat yhteen. Peli-ikkunaakaan luodessani minun ei tarvitse kirjoittaa luokan sisälle viittäkymmentä metodia, erikseen koon asettamiselle, värin vaihdolle jne. vaan voin käyttää valmiita JFramen metodeja tähän.

Kurssin aikana olen oppinut paljon, ja niinkin yksinkertainen asia kuin tämä perintä oli käsitteenä ja kaikkine ominaisuuksineen suhteellisen vajaa. Näkyvyysmääreen protected tarkoitus selvisi minulle käytännössä koodatessa, ja osoittautuikin varsin näppäräksi ratkaisuksi. Toisaalta käytännössäkään en sisäistänyt super.:n käyttöä tai lähinnä sen eroa this.:seen. This:iä käytetään kun kutsutaan jotain luokan metodia ja superia kun kyseessä on yliluokan metodi. Kuitenkin yliluokankin metodeja voi käyttää suoraan this. Tämä hämmensi täysin.

Projektissakin, nyt innostuneena tästä perinnästä loin ensin uokalle Esine viisi alaluokkaa, ja nämä toteuttamaan samat metodit. Sittemmin muutin luokan Esine abstraktiksi ja ylikirjoitin sen metodit jokaisessa sen aliluokassa. Huomasin kuitenkin kaikkien luokkien olevan niin identtisiä, että viisi luokkaa yhden enumeraation sijaan olisi ehkä sittenkin aika huono vaihtoehto. Muuten en perintää sitten hyödyntänytkään “omilla” luokilla. Sen sijaan periytin luokkia Javan valmiista luokista kuten JFrame, JPanel ja Thread.

-Meri

 

Javan oppiminen

Aloitin Studio1:n ensimmäisen kerran jo vuoden 2006 syksynä. Kuukauden myöhässä ja tarkoituksena lukea muut kiinni. Sitä riemua kesti viikon verran, jonka aikana ehdin muodostaa vahvan ennakkoluulon koodaamisen epäsopivuudesta minulle. Tämä ennakkoluulo kummiteli koko vuoden hartioillani ja oli vielä jossain määrin seuranani viime syyskuussa Studio1:n aloitusluennolla. Nyt kun kuitenkin pääsin aloittamaan puhtaalta pöydältä. Ja ehkä tuon vuoden aikana jotain tietoa ohjelmoinnista oli tihkunut myös suojakuoreni läpi, sillä alusta asti kaikki tuntui melko luontevalta ja jos ei nyt helpolta, niin ainakin luontevalta. Erityisesti alkuluennoilla (jotka siis viimevuonna missasin) asiat selvitettiin tarpeeksi yksinkertaisesti, että tajusin ettei homma ollutkaan niin vaikeaa.

Usein minulla onkin tapana uusia asioita opetellessani antaa ennakkoluulojeni vaikuttaa liikaa opiskelumotivaatiooni. Sitten kun oikeasti tarun härkää sarvista ja rupean töihin, niin yleensä huomaan ennakkoluulojeni olleen täysin tuulesta temmattuja. Niin kävi siis nytkin. Luulen myös, että kurssin rakenne, jossa ensin tehdään itse, sen jälkeen tehdään itse, sitten kysytään jokin pieni vinkki ja lopuksi taas tehdään itse, sopi minulle kuin pipo hattuun. Varsinkin kun tehtävänannot olivat melko mielenkiintoisia. Myös tarkat takarajat ja niiden rikkomista seuraavat sanktiot toimivat sopivina ruoskina työmotivaation ylläpitämiseksi.

Vaikka äsken mainitsin, että opin parhaiten tekamällä, niin sekään ei ole mielekästä, mikäli asiasta ei tiedä yhtään mitään etukäteen. Mielestäni essee-tehtävät olivat mainio tapa antaa aikaa perehtyä vaikeisiinkin asioihin ennen varsinaista aiheen käsittelyä harjoitustehtävässä. Itselläni on paha(?) tapa ryhtyä suin päin tekemään kaikkea ennen kuin otan selvää mitä ja miten pitäisi tehdä.  Voisin väittää, että ilman esseiden kirjoitusta olisin ollut paljon pahemmin hukassa harjoitustehtävissä ja aikaa niihin olisi kulunut vähintään yhtä paljon enemmän kuin mitä esseiden kirjoittamiseen meni. Vaikka lopullinen oppiminen tapahtuukin vasta itse tekemällä, niin useamman tunnin etukäteisperehtyminen helpottaa tätä oppimisprosessia huomattavasti.

Vastaavasti OLO-sessiot eivät tarjonneet välttämättä samanlaista hyötyä ohjelminnilleni. Syitä siihen on varmasti useita. Päällimmäisin syy on varmasti laiskuus. En rehellisesti sanoen panostanut yhteenkään oppimistavoitteeseen kahtakymmentäminuuttia enempää. Mutta tämä kahdenkymmenen minuutin satsaus riitti, eli pystyin selittämään jotain kummallista purkusessioissa niin että homma meni täydestä. Ehkä jonkinnäköinen kirjallisena vaadittava tuotos oppimistavoitteista olisi saattanu toimia pienenä boostina. Toisaalta olin myös ehtinyt turhautumaan koko OLO-menetelmään edelliskevään Studio2-kurssilla. Jotenkin melko usein tuntuu, että silmittömällä lappujen roiskimisella taululle ei saavutettu mitään muta kuin sekaannusta.  Tästä on taas muodostumassa yhdenlainen ”perusennakkoluulo”, joista olisi syytä päästä varmaankin eroon (kun nyt näitä OLO-kursseja nyt vielä sattuu olemaan jäljellä).

Myös tämä blogiinkirjoittaminen ei oikein tuntunut täysin luonnistuvan. Kyseinen toimitus oli aina helppo heittää priorisoinnissa viimeiselle sijalle, koska ei ollut mitään ns. ”pakollisia” kirjoituksia, eli kirjottaa sai aina kun ehti. Ehkä omaa oppimistani leimaa jonkinnäköinen ruoskan tarve. Tarvitaan joku taho, joka ravistelee tietyin uhkavaatimuksin tekemään hommia ajallaan.

-Ville

Kuulutko joukkoon?

Matemaattisesti joukko on ”toisistaan erotettavien objektien (olioiden) yhdistelmä” [1]. Joukko voi olla vaikka ihmisjoukko, kokonaislukujoukko tai suomenlapinkoirajoukko :hopeanuoli:. Javassa joukko ei ole mikään hämärä käsite – ”rakas” ohjelmointikielemme tuntee samat eksaktit käsitteet kuin matematiikkakin: leikkaus (intersection), erotus (difference) ja yhdiste (union). Itse asiassa Javan joukko jäljittelee matemaattisen joukko-käsitteen mallia.

Joukot ovat tuttuja otuksia Java-kotitehtävistä. Javassa joukoilla on joskus varsin näppäräksi osoittautuva ominaisuus: ne ottavat alkiokseen vain yhden identtisen alkion, joten ne sopivat hyvin vaikkapa mallintamaan sienikoria. Eihän kukaan sienestäjä nyt kahta saman sienilajin sientä poimisi, eihän? Mikäli joukko sisältää jo alkion ”kanttarelli”, ei toista samannimistä alkiota ”kanttarelli” huolita enää mukaan. Tietysti jos näiden herkullisuus-arvo on eriävä, niin silloin tarkkasilmäinen sienestäjä huomaa eron ja kelpuuttaa tämän henkilökohtaiseen sienikori-joukkoonsa.

Samassa joukossa ei siis voi olla alkioita a ja b siten että a.equals(b); on tosi [2]. Kaksi joukkoa ovat ekvivalentit (samat) jos ne sisältävät samat alkiot.

Java.util.Set on rajapinnan Collection<E> alirajapinta. Itse asiassa Set on kokoelma, joka toteuttaa ainoastaan Collectionin metodit sisältäen samalla tupla-alkioiden eston [2]. Set-rajapinnan toteuttavia joukkoja ovat mm. TreeSet, HashSet ja LinkedHashSet. Set-rajapinta ei määrittele joukolle mitään tiettyä järjestystä. Jos on tarve käyttää joukkoa ja järjestää alkiot tiettyyn järjestykseen, tarvitaan SortedSet-rajapinnan toteuttava joukko. Joillakin Setin toteutuksilla on tietynlaisia rajoitteita lisättäville alkioille, esim. jotkut joukot eivät ota alkioikseen null-arvoja[2].

HashSet on monipuolinen tietorakenne. Jos nyt haluaisimme luoda vaikkapa tällaisen HashSetin, voimme lausua taikasanat:

Set<NoJaa> blaa = new HashSet<NoJaa>();

Tämä joukko ottaa alkioikseen ainoastaan NoJaa-luokan (ja sen jälkeläisluokkien) ilmentymiä.

Koska Javan joukko toteuttaa Collection-rajapinnan, kaikki tutut tietorakenne-metodit ovat käytössä. Voidaan lisätä (add) tai poistaa alkioita (remove) tai tarkistaa, sisältääkö joukko tietyn alkion(contains). Joukon läpikäymiseen tarvitaan erillinen iteraattori-olio, mutta se on pieni miinus ottaen huomioon joukon helppokäyttöisyyden ja monipuolisuuden tietorakenteena.

– Teemu

[1] Joukko-oppi, Wikipedia
[2] Java API SE 5.0: Set

Mitä paljastetaan kaikille, mikä pidetään omana tietona? Siis näkyvyysmääreistä

Mitä hyötyä on erilaisista näkyvyysmääreistä: public, private, protected? Miten ohjelmointiin vaikuttaisi, jos kaikki muuttujat olisivat tyyppiä public? Entäpä, jos kaikki olisivat tyyppiä private?

Pitkälle syksyyn pärjäsin sillä tiedolla, että attribuutit määritellään privateiksi ja metodit publiciksi. Välillä ohjelmointitehtävissä kyllä neuvottiin metodille jokin muu näkyvyysmääre, private tai protected, ja niin sitten tein enempää miettimättä, että miksi näin. Jo kurssin alussahan tuli esille, mitä tarkoittaa, jos näkyvyysmääre on public tai private. Private-määriteltyä voi käyttää vain luokan sisällä (tai luokan sisäluokassa), ja public-määriteltyä kaikkialla, siis myös muissa luokissa. Harvinaisempi ja minulle vähiten tuttu on protected, jonka opin tuntemaan vasta myöhemmin. Sehän laajentaa näkyvyyden luokan sisältä myös sen jälkeläisiin.

Aloin miettiä näkyvyysmääreiden merkitystä vasta viimeisissä tehtävissä, vaikka ne ovatkin melko merkityksellinen ja  näkyvä osa ohjelmointia. Asia tuli esiin apumetodeita tehdessä, niitähän pitää voida kutsua vain kyseisessä luokassa metodissa, jonka avuksi ne on tehty. Muistin myös ohjeen, että näkyvyydeksi pitäisi laittaa mahdollisiman suojaava määre. Ja niin eivät metodini enää olleetkaan aina public.

Attribuuttien kohdalla taas en muista käyttäneeni muuta näkyvyysmäärettä kuin privatea. Toisaalta muulle ei usein taida olla tarvettakaan tai ei se ainakaan hyvä vaihoehto yleensä ole. Attribuutteihin kun ei ole yleisesti tarkoitus päästä käsiksi muissa luokissa. Mutta jos siihen on tarvetta, on parempi tehdä publiciksi määritelty metodi, joka tarjoaa attribuutin muiden luokkien käyttöön, kuten mahdollisuuden muuttaa tai tiedustella attribuutin arvoa. Jossain tapauksissa attribuutin näyttäminen myös luokan jälkeläisille voisi olla perusteltua eli määritellä se protectediksi, mutta attribuutin jakaminen kaikelle maailmalle publicilla on kyllä yleensä liian avointa. Kuitenkin jos attribuutti on jokin pysyvä vakioarvo ja sitä tarvitaan muissa luokissa, voi public-määrettä hyvin käyttää.

Jos ainut näkyvyysmääre vaihtoehto olisi private, tarkoittaisi se, ettei mitään luokkien metodeita voisi kutsua muissa luokissa. Luokat eivät voisi kutsua edes toistensa konstruktoreja, eli luoda luokkien uusia ilmentymiä. Ohjelman kannalta tämä ei toimisi, koska pääohjelmaluokka ei saisi yhteyttä muihin luokkiin, eli ne jäisivät käyttämättä. Jos taas kaikki olisi määritelty määreellä protected, seuraus olisi sama, paitsi jos ohjelman luokat periytyisivät toisistaan, jolloin kaikki voisivat käyttää aina ylempien luokkiensa metodeita. Monimutkaisemmissa ohjelmissa näin yksinkertaisia luokkakaavioita harvoin voisi toteuttaa.

Kaiken olessa taas määritelty publiciksi, kaikki metodit olisivat kaikkien luokkien käytössä, mikä ei ehkä olisi kovin suuri ongelma. Niin olisivat myös attribuutit eli kaikki voisivat muuttaa attribuuttien tietoa. Itse asiassa en tiedä, mikä siinä sitten kauheasti haittaisi, jos vain koodaisi siten, ettei luokissa koskisi toisten luokkien attribuutteihin. Eiväthän ne silloin muuttuisikaan perättömästi. Toisaalta, kun ajattelee asiaa olioiden kautta ja muistaa, että attribuutti on olion ominaisuus, on privateksi määritelty attribuutti paras. Tällöin olio voi itse kontrolloida attribuuttien käyttöä, esimerkiksi määrittelemällä attribuuttia muuttavan metodin, jossa myös määritellään, millaiset arvot attribuutille voi antaa. Muut luokat voivat muuttaa attribuuttia vain tämän metodin kautta, eli olion tahdon mukaisesti. Näkyvyysmääreitä kannattaa siis miettiä, vaikka ne melkein luonnostaan alkavatkin tulla metodeille publiciksi ja attribuuteille privateiksi. Ja itseäni ainakin auttaa sääntö, että näkyvyysmääreeksi kannattaa valita mahdollisiman suojaava määre.

-Anu

Miksi ohjelmaa kannattaa jakaa eri luokkiin? Miksei riitä, että on vain yksi luokka, jossa on kaikki koodi?

Java on monen muun ohjelmointikielen tapaan puhtaasti olio-pohjainen. Mitä tarkoitetaan olio-pohjaisella? Ideana on jakaa ohjelma moneen osaan eli luokkaan ja muodostaa luokista ilmentymiä eli olioita. Miksi näin kannattaa tehdä vai kannattaako edes? Eikö yksi luokka riiittäisi hoitamaan kaiken tarpeellisen.

Luulisin, että yhdessä luokassa pystyy tekemään kaiken saman mitä monessa eri luokassa ja luultavasti ilman metodejakin pärjäisi pitkälle. Main-metodiin vaan kaikki koodi ja lopputulos saattaisi olla sama. Koodin jakamisessa moneen luokkaan on kyse ennemminkin selkeydestä. Varsinkin kun kyseessä on hiukan isompi ohjelma, on huomattavan fiksua pilkkoa se moneen osaan eli tavallaan jakaa iso ongelma moneksi pieneksi. Selkeämmän lopputuloksen lisäksi tälläinen ratkaisu tekee virheiden etsimisestä paljon helpompaa ja mahdollistaa ohjelman muokkaamisen jälkikäteen paremmalla menestyksellä. Esimerkiksi useat ohjelmointioppaat suosittelevat pitämään logiikan ja käyttöliittymän erillään toisistaan. Tämä juuri sen takia, että käyttöliittymän ulkoasua voi muokata mieleisekseen jälkikäteen, eikä tarvitse kajota logiikkaosioon.

Monen luokan käyttö on perusteltua lisäksi sen takia, että varsinkin isot ohjelmat eivät ole vain yhden ihmisen käsialaa ja niihin tullaan mahdollisesti jonkun muun toimesta todennäköisesti kajoamaan vielä tulevaisuudessa. On tärkeää, että ohjelma on selkeä ja sen rakenne helposti ymmärrettävissä. Henkilön, joka ei ole ennen kyseistä ohjelmaa nähnyt, on helpompaa päästä jyvälle, mikäli koodi on jaoteltu selkeisiin osa-alueisiin, luokkiin, joilla on yksi määrätty tehtävä. En voi kuvitellakaan millaisen sekamelskan saisi aikaan tekemällä ison ohjelman yhteen luokkaan.

Onko monen luokan käytössä haittapuolia? Itse en ainakaan tiedä, enkä nopealla googlaamisellakaan löytänyt mitään suurempia haittapuolia. Luulisin, että jotakin ohjelman hitauteen liittyviä ongelmia voi muodostua jos viittauksia eri luokkiin vilisee ristiin rastiin. Tiedä häntä. Itselläni haittapuolet esiintyivät lähinnä hermojen menemisenä luokkien välisten suhteiden kanssa, tämä luokka tuntee tuon luokan ilmentymän, tämä taas tuon, jne. Joskus tuntui, että olisi tosiaan ollut helpompi tehdä vain yksi iso luokka, niin ei olisi ollut ongelmia viittausten kanssa. Ongelmat kyllä ratkesivat aina lyhyen pohdinnan jälkeen ja tulos oli huomattavasti loogisempaa, kuin yksi iso luokka. Mielestäni monen luokan käyttö on erittäin perusteltua juurikin selkeyden takia.

-Olli