You are currently browsing Moona's articles.
No jep, ohi on, ja unohin, että tämä loppupuheenvuorokin piti kirjottaa.
Eri näkyvyysmääreitä käytetään eri tilanteissa: Määre public näkyy kaikille. Private näkyy vain sen luokan sisällä, missä sitä on käytetty. Protected näkyy luokassa ja sen jälkeläisissä. Lisäksi on oletusmääre, joka on voimassa, jos mitään muuta määrettä ei anneta. Oletus näkyy saman pakkauksen luokissa sekä luokan jälkeläisissä.
Jos kaikki olisi määritelty oletuksella, niin luokan jälkeläisissä ja sen kanssa samassa paukkauksessa olivissa luokissa voisi muuttaa esimerkiksi jonkin tärkeän vakion arvoa. Esimerkiksi piin arvoa ei voisi muuttaa, koska se on määritelty final-määreellä, mutta jos käyttää jotain tärkeää arvoa, joka voi kuitenkin muuttua, mutta vain jos ohjelmoija niin haluaa tai vain tämän tietyn luokan toiminnot niin päättävät. Tässä tilanteessa, kuitenkin, joku saattaa luoda tälle tärkeän muuttujan sisältämälle luokalle aliluokan ja muuttaa siellä tämän muuttujan arvoa. Tai jokin samaan luokkapakkaukseen kuuluva saattaa muuttaa tätä arvoa, vahingossa tai tarkoituksella. Tämän takia private-määre on tarpeellinen.
Toinen tapaus taas on se, ettei jokin luokka ole samassa pakkauksessa kuin jokin tärkeä tai monimutkainen metodi, eikä tätä luokkaa voi laittaa myöskään perimään tätä metodin sisältävää luokkaa. Tällöin taas tarvitaan public-määrettä.
Samoista syistä kaikki muuttujat eivät voisi olla tyypiltään vain privatea – miten silloin voitaisiin kutsua muissa luokissa olevia metodeja? – eikä myöskään vain publicia – miten tällöin suojataan esimerkiksi suojausta tarvitsevat attribuutit?
Protected-määrettä voidaan näin ollen käyttää kun muuttuja tarvitsee suojaa muita paitsi jälkiläisiään vastaan.
Kaikista eri näkyvyysmääreistä on siis hyötyä.
Metodeja tarvitaan ensinnäkin selkeyttämään koodia. Jos olisi yksi metodi, niin olisi vaikeaa tietää, missä kohtaa sitä mikäkin asia hoidetaan. Asian helpottuminen monimetodisessa koodissa edellyttää sitä, että antaa metodeille kuvaavat nimet. Näiden nimien avulla on paljon helpompi pysyä kärryillä siitä, mitä missäkin tehdään.
Voisihan sitä ajatella, että kun se on kerran kirjoitettu, niin ei sillä sitten ole enää mitään väliä, että onko esimerkiksi aloita alusta -kuuntelija nyt tämän parin tuhannen rivin koodin alku vai loppu puolella. Mutta mitä sitten tehdään kun ohjelma ei toimikaan; lähdetään selaamaan pari riviä kerrallaan koko koodia läpi vai? Tässä on yksi syy metodien käyttöön.
Toinen hyvä syy käyttää metodeja on toiston väheneminen. Entä jos ohjelmassa on vaikka tuollainen edellä mainittu aloita alusta -toiminto tai vielä parempaa: aloita uusi
-toiminto? Kirjoitetaanko silloin tuon kuuntelijan sisälle kaikki se, mitä uuden ohjelman aloittamisessa tarvitaan – uudestaan? Sillä luultavasti ohjelman aloittaminen täytyy koodata tapahtumaan muutoinkin kuin uuden ohjelman aloittamiseen tarkoitettua nappia painamalla. Tai voisi tuota nappia tässä tapauksessa ehkä vaatia painamaan, mutta kaikissa ohjelmissa tämä ei onnistu ja toistoa tulee varmasti.
Kolmas hyvä syy käyttää metodeja on se, että niitä voi käyttää erikseen luokan ulkopuolelta. Toisaalta, jos tekee vain yhden luokan, niin eihän näitä metodeja tultaisi käyttämään sen ulkopuolelta, mutta koska päädyimme jo siihen, että se oli hyvin epäselvää ja bugien ja muiden virheiden korjaamiseen ja ymmärtämiseen menisi luultavasti hirvittävästi aikaa, niin oletetaan, että luokkia olisi monta, metodeja jokaisessa se yksi. Luokkia olisi silloin vaikea lukea samalla, joutuisi kokoajan vaihtamaan ikkunaa. Lisäksi pitäisi aina luoda uusi luokka, määritellä se ja sitten tehdä vielä kuitenkin se metodi. Mieluummin siis toisin päin: yksi luokka, monta metodia.
Selkeintä ja toistoa vähentävintä olisi kuitenkin käyttää tarvittavan montaa luokkaa, jotka voi laittaa perimään eri muita luokkia ja tehdä niihin useampia metodeja, jotka käsittelisivät kukin yhtä asiaa, löytyisivät helposti, ja joita voitaisiin kutsua näistä toisista luokista sekä vain silloin, kun se on tarpeellista.
Näin siis, hieman myöhässä, tulee minun sepustukseni siitä, kuinka meidät tömäytettiin swingillä ja käyttöliittymillä pois pikkuhiljaa turvallisen tuntuiseksi muuttuneilta raiteilta. Toisinsanoen uusi ohjelmointiaihe, Sikoban, ja sen graafinen toteutus lätkäistiin neniemme eteen juuri, kun tuntui siltä, että hei, minäpä taidan osatakin hieman javaa.
Tämä valekuva rikottiin (tai paremminkin häivytettiin, olematonta on vaikea rikkoa ja valekuvathan eivät ole olemassa) viidennessä ohjelmointiharkassa J-alkuisilla luokkanimillä eli käsittämättömän monilla erilaisilla valmiskomponenteilla, joilla piti luoda kehykset, paneelit, ruudukko ja valikko Sokoban-pelille, jossa seikkailivat siat ja betonipossut. Pelissä työnnettiin betonipossuja tieltä samalla kun suunnattiin kohti maaliruutua. Onneksi pelilogiikan väsääminen oli hieman tutumpaa puuhaa – hieman.
Oli tietenkin mielenkiintoista oppia swingin luokkarakenteen käyttöä ihan koodauksessakin, ja olisihan sitä kuvitellut, että aiheesta kirjoitettu essee olisi valmistanut edes jotenkin, mutta minä ainakin olin melko hukassa, kun katselin ensimmäisiä osatehtäviä. Saattoi tietenkin johtua minun tapauksessani siitä, että englanti ei ole kovin hyvin hallussa ja swing-luokkista selvää saaminen tuskastutti melkoisesti.
Swing-svengailun lisäksi muuta erikoista tässä javatehtävässä oli osatehtävien suuri määrä (10kpl), johon ei oikein tiennyt, miten suhtautua; ne kun sattuivat olemaan aika erilaisia kooltaan, joten oli vaikea arvioida kauanko pitää varata aikaa niistä mihinkin.
Tehtävänannon alussa oleva kehotus lukea osatehtävä kokonaan läpi ennen koodin kirjoittamista tuntui ensin omituiselta, mutta kyllä sen hetken päästä tajusi järkeväksi. Ohjeosan lopusta löytyi yleensä jotakin selventävää, yhtenäistävää tai idean esille tuovaa, ja itse ainakin päädyin tekemään metodeja eri järjestyksissä kuin ne oli lueteltu, koska kuvittelin, että joidenkin oikeat muodot olisivat olleet monimutkaisempia kuin mitä keksin. Usein kyllä selvisi muutaman myöhemmin mainitun metodin tekemisen jälkeen, että eihän tämä olekaan tätä vaikeampi; harhaan johtava vain. Esimerkiksi Peliruudukko-luokassa, kuten melkein kaikissa muissakin luokissa, loin muita yksinkertaisempia metodeja ennen kuin aloin ihmettelemään konstruktoria.
Myös bonustehtävät olivat jotain uutta, johon oli vaikea suhtautua: Onko niitä pakko tehdä, jos haluaa hyvän arvosanan? Kuinka paljon täytyy tehdä, jotta ne vaikuttaisiva? Voiko niistä olla haittaa?
Ehkä voisin tässä vielä mainita, että minusta vaikeimmat asiat ymmärtää tässä tehtävässä olivat kuuntelijat sekä FileChooser. Vaikka siis muunkin uuden omaksuminen oli haastavaa. Ja omaksuttavaa kyllä riitti.
Ensinnäkin, olen pahoillani, että sotkin hienon järjestyksemme ja uuden tehtävän alustus ehti ilmestyä tänne ennen tätä 3. tehtävän purkua. Tässä tämä nyt kuitenkin on.
Kolmas purku siis tuli ja meni mukavasti lakinlaskiaisia seuraavana päivänä ja tunnelma oli melko väsynyt. Jotain saatiin silti aikaan: Selvisi, että sanakirjarakenteessa voi olla enintään yksi arvo yhtä avainta kohtaan, vaikka monet avaimet voivatkin viitata tähän arvoon. Enintään-sana tarkoittaa tuolla, että arvo voi olla myös null.
Saimme myös kuulla, että taulukon ja joukon yhdistäminen on mahdollista samoin kuin muidenkin tietorakenteiden. Ensisijaisesti ajattelimme tuolla, että niitä voi laittaa sisäkkäin, mutta niitä pystyy ilmeisesti myös lomittamaan.
Näiden lisäksi olimme valinneet oppimistavoitteiksi keksiä tietorakenne palalle kohtaan 5. sopiva ratkaisun sekä suunnitella tietorakenteet molempiin tietorakenne maailman kohtiin. Pala päätettiin laittaa taulukoksi, jonka sisällä on luokkia ja olioita.
Rajoitetusta maailmasta taas päätettiin tehdä matriisi taulukon ja sen sarakkeisiin asetettavien uusien taulukoiden avulla. Tästä mallista ilmestyi myös havainnoiva kuva taululle yksinkertaisen matriisinohjelmointiesimerkin viereen. Rajoittamattomassa maailmassa päädyimme lopulta käyttämään listoja samaan tapaan kuin edellä taulukoita ja määräämään, että jos listan kohdan arvoksi on asetettu null, niin siinä kohdassa ei ole laattaa.
Yleisesti oppimistavoitteet taisivat olla tällä kertaa melko yksioikoisia, joten purustakaan ei kovin erikoista pohdintaa syntynyt. Asiat tuli kuitenkin selvitettyä ja saimme tästä varmasti hyödyllisiä vihjeitä java-ohjelmoinnissa tulevaisuudessa vastaantulevien tietorakennevalintojen tekemiseen.
