wiki:KysymyksiaJaVastauksia
Last modified 5 years ago Last modified on 2013-03-24 00:26:18

Kysymyksiä ja vastauksia

15.1.2011

Käyttöliittymästä

  • Saako ComboBoxiin ajon aikana haluamiaan tietoja?
    • Toki saa, kaikkien komponenttien kaikkia "arvoja" (= properties) pystymme aikanaan muuttamaan ihan mielivaltaisesti, kunhan pääsemme tänne saakka. Suunnitteluvaiheessa niihin voidaan (ja kannattaa) antaa "leikkiarvoja", jotka näyttävät käyttöliittymää katsellessa "oikealta".
  • Miten kun käyttöliittymä ei näytä "samanväriseltä kuin suunnittelin"?
    • Swingissä käytetään "look and feel", jolloin sama käyttöliittymä voi näyttää erilaiselta eri järjestelmissä. Jos WindowBuilderin asetukset ovat kuten Wikissä neuvottiin, niin "look and feeliä" voi vaihtaa suunnittelunäkymän yläpuolella olevasta pienestä rattaasta (jonka vieressä oletuksena lukee <system>) ja sieltä ottaa haluamansa "look and feel".
  • Onko lista vai ComboBox parempi?
    • Kaikki riippuu aina käyttötilanteesta. Jos listat ovat selkeästi rajoitetun kokoisia, niin peruskäyttäjille helpoin voi jopa olla joukko allekkain olevia RadioButtoneita tai CheckBoxeja sen mukaan saako valita monta vai yhden. Yleensä ComboBox on jopa huonoin, sillä siinä käyttäjän pitää klikata, että näkee mahdolliset valinnat. Eli ComboBox silloin kun halutaankin ettei käyttäjä valitse mitään :-) (Kuten malliohjelman hakutoiminnassa useimmat hakevat nimellä).
    • Erityisesti jos pitää valita monta alkoita, niin silloin on havaittu että listasta ctrl/shhift temppuilut ovat tavalliselle käyttäjälle liikaa ja ne osaavat paljon paremmin pistää rukseja valintojen viereen. Tällaista ruksilistaa sitten voi vielä auttaa "Valitse kaikki"/"Tyhjennä kaikki" toiminnoilla.
  • Yksi ikkuna jossa on paljon toimintoja vaiko monta pientä?
    • Riippuu taas käyttökohteesta ja käyttäjäryhmästä. Yleensä pieni ikkuna jossa on vähän valintoja on peruskäyttäjälle helpoin. Kokenut käyttäjä taas voi hermostua jos ikkunoiden välillä pitää jatkuvasti hyppiä. Adaptiivinen käyttöliittymä olisi ihanne, mutta sellaisen tekeminen on todella haastavaa.
    • Sitten on vielä yksi vaihtoehto: JTabbedPane (lärpsykkäkirja, eli joukko välilehtiä, joissa asiat on yhteenkuuluvuuden perusteella jaoteltu eri välilehdille). Jos joku tätä käyttää, niin voisi itse asiassa kirjoittaa sille ohjeita tuonne:
    • Sitten jos ikkunassa on samassa näkymässä paljon asioita, niin huomatkaa että panelilla (ja monella muulla) on border-ominaisuus, joita luovasti käyttämällä voi koristella ja jaotella ikkunaa selkeämmin. Antamalla borderiin marginaalia, saadaan enemmän tyhjää tilaa asioiden ympärille. Tästäkin joku voisi kirjoittaa tuonne em. wiki-sivulle käyttöohjeita kun kokeilee.

SVN ja muut käyttikset

  • Miten Mac ja SVN?
    • Itse en tiedä Mac:in SVN -käyttöliittymistä, mutta joka tapauksessa [ohj2Eclipse Eclipseen] saa SVN-pluginin:
    • Eclipse SVN-pluginilla SVN:ään saa "Graafisen käyttöliittymän" vähän kuten Tortoisessa. Windowsissa vaan henkilökohtaisesti pidän TortoiseSVN:ää helpompana kuin Eclipse pluginia, tosin ei noilla hirveän suurta eroa ole.
    • Ja erityisesti: Kaikkia SVN:än käyttöliittymiä voi käyttää ristiin. Välillä voi tehdä toisella ja välillä toisella. Aivan kuten Java-koodia voi kirjoittaa Notepadillä tai Eclipsellä tai millä tahansa muulla editorilla.
    • Eclipsen projektia vaan joutuu virkistämään (F5, Refresh) jos svn:ää käyttää välillä jollakin muulla käyttöliittymällä (komentorivi, Tortoise jne).

7.2.2008

Olen hieman muutellut kysymysten järjestystä ja laittanut saman otsikon alle, jos on ollut useampia yhteen liittyviä kysymyksiä.

Rajapinta

  • Mistä saisi lisää (selkeää) tietoa rajapinnoista ja niiden tekemisestä?
  • interface-käsite?
  • Miten rajapintoja käytetään ja mikä oli ero perintään?
    • lue myös Perintä vs Rajapinta
    • Näistä tulee myöhemmin kurssilla lisää. Erona perintään on se, että rajapinnan perimällä saa vain rajapinnan ja kaikki metodit joutuu tekemään itse. Perintä tuo mukanaan jo mahdollisesti joukon toteutuksiakin sekä yliluokan attribuutit ovat olemassa.
    • Tuota Sunin Tutorialia voisi vilaista.
    • Rajapinta on sopimus. Se kertoo, millaisia metodeja rajapinnan toteuttava olio tarjoaa käytettäväksi, ja millaisia metodeja olion käyttäjä voi kutsua. Rajapinta piilottaa toteutuksen, eli ei ole tarve kysellä, eikä tulisi olla tarve kysellä, mikä olio ja miten toteuttaa rajapinnan metodit. Oliota ja metodeja voi siten käyttää mukavasti rajapinnan läpi. --ji
    • Rajapinta voi periä toisen rajapinnan, mutta luokka voi vain toteuttaa rajapinnan. Perintä ja rajapinta ovat käsitteinä siten vertailukelvottomia, toinen on kohde, toinen operaatio. Rajapinnan perintä eroaa luokan perinnästä siten, että rajapinnan perinnässä ei tule piirteiden toteutuksia mukana, kun luokan perinnässä ne tulevat. --ji

Perintä

  • Milloin kannattaa käyttää perintää, missä vaiheessa on helpompi tehdä oma, uusi luokka tai olio?
    • Oikeastaan asiaa ei ehkä kannata ajatella aluksi noin. Ajattelee ensin aina sitä lopputuoteoliota ja mitä siltä haluaa. Kun tekee tai suunnittelee muita ohjelman olioita, niin saattaa huomata eri olioilla jotakin yhteistä. Jos yhteinen on samat toiminnot, mutta eri sisällöt, niin silloin oliot luodaan saman luokan pohjalta. Erona on attribuuttien arvot (eli olion tila). Jos oliot ovat erittäin samankaltaisia, mutta toiminnoissakin on lieviä eroja, niin silloin voidaan yhteisen kantaluokan ja perinnän kautta saada haluttu tulos vähemmällä koodaamisella. Ilman perintääkin pärjää aika pitkälle, mutta silloin tulee toistettua samaa koodia. Toki toisinpäin ajatellen jos on jo valmis luokka, joka melkein sopii haluttuihin tarkoituksiin, niin silloin sen periminen ja haluttujen ominaisuuksien lisääminen voi olla hyvä ratkaisu. Graafisissa käyttöliittymissä luodaan esimerkiksi tällä tavalla uusia käyttöliittymäkomponentteja. Sitten Javassa muuten on aina tehtävä luokka jotta saa yhdenkin olion :-)
    • Perinnälle on myös toinen syy olemassa tuon toiminnan kopioimisen lisäksi, ja se on tyypin periytyminen. Tämä on hyvin vahvasti sama asia kuin rajapintojen toteuttaminen, ja usein tähän nimenomaiseen tarkoitukseen käytetäänkin javassa rajapintoja, katsokaa esimerkkinä java.io.Serializable-rajapintaa (JDK1.6 Serializable). Siinä ei ole esitelty yhtään toteutettavaa metodia!
  • Moniperintä?
    • Lyhyesti: Javassa yksinkertaista. Sitä ei ole! Pitemmin: vastaavaa voi toki toteuttaa rajapintojen kautta ja rajapintoja yksi Java luokka voi toteuttaa (implements) vaikka kuinka monta kappaletta. Luokka voi periä (extends) vain yhden luokan. Oikeastaan tuleekin monesti ongelmaksi se, että periikö vai käyttääkö rajapintaa. Jos perii, niin se ainoa perintä on silloin käytetty. Jos käyttää rajapintaa, niin silloin pitää tehdä kaikki itse ja ei saa apua edellisestä toteutuksesta. (Jos ei halua tehdä kaikkea uusiksi, voi aina delegoida. Kysykää Vesalta lisää ;) --ji) Polymorfismiedut toki saa molemmilla.
    • Esimerkiksi C++:ssa on moniperintä, mutta ei rajapintoja. (C++:ssa on kyllä aidosti abstraktit luokat, jotka vastaavat rajapintoja lähes täysin. Ne ovat kuitenkin luokkia, eivätkä eriteltyjä omaksi rakenteekseen, kuten rajapinnat javassa. --ji) Rajapintoja voi toki helposti toteuttaa perinnän avulla. Moniperinnän ongelmana on se, että jos perityillä luokilla on yhteinen kantaluokka jossakin ja siinä attribuutteja, niin silloin moniperinnässä ei ole selvää että kummanko kantaluokan attribuutti tulee uuteen luokkaan. Osittain sama koskee myös metodeja. Perintähierarkiasta syntyy salmiakkikuvio. Katso esimerkiksi: Olio-ohjelmointi ja C++, luku Peritään suoraan useampia luokkia ja tuosta lue koostamislukuun saakka.
  • Voiko luokka A periä ominaisuutensa luokalta B joka on jo perinyt ominaisuutensa luokalta C? Vrt. Elain <- Nisakas <- Koira jne.
  • Voiko luokkia periä useammasta tasosta? Ks kuvia:
      Elain
        ^
        |
    Lentavaotus
        ^
        |
     Lepakko    
    
    Eli class Lentavaotus extends Elain...
        class Lepakko extends Lentavaotus...
    
    • Ehdottomasti voi. Ja niin tehtiin jo KissaP:n kanssakin:

Elain extands Object... Kissa extends Elain...

Tuo perimähierarkia voi olla hyvinkin syvä. Esim. graafisen käyttöliittymän kirjastoissa helposti 10 tasoakin.

Metodien dynaamisuus

  • Voiko saman kuokan eri olioilla olla oma metodi? Esim:
      Kissa luokan olioilla mirri ja miuku luokan metodien lisäksi
      joku oma metodi, kuten mirri.juokse(); miuku.kavele();
      mutta ei ole olemassa mirri.kavele(); miuku.juokse();
    
    • Javassa ei ihan helposti. Pakko olisi tehdä nuo kantaluokkaan ja sitten vaan estää niiden käyttö jonkin attribuutin perusteella tietyissä olioissa.

Aliohjelma vai olio

  • Mistä asioista kannattaa tehdä olioita eikä vaikka vain aliohjelmia?
    • Vaikea kysymys :-) Ehkä niin että jos tehtävä on tehtävissä aliohjelmalla, jolle riittää kohtuullisen lyhyt parametrilista, niin silloin aliohjelma. Jos tehtävän tekemiseen tarvitaan useita kutsuja joiden välillä tietoa pitää säilyttää, niin silloin olio.
    • Jos toimintaa pitää muuttaa tai vaihtaa ajon aikana tai ohjelmaa käännettäessäkin, kannattaa tehdä olio aliohjelman sijaan. Paitsi jos ei kannata :) Helpoiten ja parasta tämä on selvittää sitten kun on yhden mahdollisen toteutuksen tehnyt. --ji
  • kuinka paljon oikeassa isossa ohjelmassa on eri luokkia (olioita)? Max? Voiko niitä olla liikaa?
    • Esim. Korpissa on Java-tiedostoja vähän reilu 1000 kappaletta ja lisäksi toinen mokoma JSP-sivuja, jotka kääntyvät luokiksi. Olioita on toki enemmän, koska jokainen käyttäjä luo Korppiin useita olioita. Muisti on rajana.
  • Miten oliota verrataan keskenään?
    • Tästä tulee kohta demotehtäviä, mutta lyhyesti:
         if ( olio1.equals(olio2) ) ...
         if ( olio1.compareTo(olio2) < 0 ) ...
      
  • Mihin olioita tarvitaan?
    • Tähän ei lyhyttä vastausta ole, mutta aluksi:
      1. selkeyttämään kokonaisuutta
      2. jakamaan vastuut niille joille ne kuuluvat
      3. viemään ohjelman koon kriittistä rajaa ylöspäin
      4. "mallintamaan arkiympäristöä" (Joskus "arkiympäristö" on hyvin kaukana arjesta! --ji)
      5. hyvä olio(kirjasto) voi olla kohtuullisen työläs tehdä, mutta sen käyttö voi olla erittäin helppoa. Esimerkkinä vaikka monet Java-valmiit luokat tai graafisten käyttöliittymien komponenttikirjastot.
    • Ei olioita mihinkään tarvita! Ihan hyvin voit tehdä kaiken sen minkä olioilla teet jollain muulla tavalla. Oliot ovat vain erilainen tapa hahmottaa kokonaisuuksia ja koostaa ratkaisuja. Minkä tavan valitsee riippuu siitä, kuka on valitsija ja mikä on ongelma. --ji
  • Oikean olion main.metodin käyttötarkoitus - jätetäänkö se tyhjäksi?
    • Kyllä yleensä. main on sitä varten että voidaan ajaa siitä alkava ohjelma ja jos ohjelma sisältää kymmeniä tai satoja luokkia, niin main-metodeja ei tarvita kuin yksi, se joka luo ohjelman ensimmäiset oliot.
    • Nipotus-osastolta sanotaan seuraavaa: Oliolla ei ole main-metodia, se on olion luokan metodi. Oliolle voi toki tehdä main-metodin, mutta se ei olisi mitenkään erikoisasemassa muihin metodeihin verrattuna. Luokan main-metodi taas on erikoisasemassa, kuten tiedetään. --ji
  • Voidaanko hieman sivuta käyttöliittymän toteutusta olioilla?
    • Jatkossa kyllä sivutaankin. Johan nytkin malliohjelman Naytto-luokka on olio. Se kuinka pieniin tuo jaetaan on toinen juttu. Sitten meille tulee esimerkkejä loppukurssista graafisista käyttöliittymistä. Jos miettii miten menut tekisi fiksusti ja haluaa mennä asioiden edelle, niin voi katso kurssin viimeisten demojen tehtäviä 4-6. Täsmälleen samalla idealla voidaan tehdä menutkin ja saadaan ohjelma jossa on toiminnot erikseen ja menurakenne helposti muutettavana toimintojen yläpuolella.

Valmiit luokat ja aliohjelmat

  • Kannattaisiko sitä aliohjelmakirjastoa (Ali.jar) oikeasti käyttää? Olenko kovempi jätkä jos en käytä?
    • Kovempi voit olla, mutta tyhmempi :-) Aika ja energia kannattaa uhrata omaan työhön liittyvien uusien asioiden keksimiseen ja antaa testattujen osien hoitaa rutiineja. Erityisesti kun kirjasto on täysin vapaata riistaa jolloin sen voi viedä milloin tahansa mihin tahansa mukanaan.
  • Neuvoja valmiiden luokkien hakuun (mistä etsiä/miten)?
    • Lue Java Tutorial, varsinkin kohdat "Essential Java Classes" ja "Collections" (Java Tutorial). --ji
    • Tämä onkin Javan vaikein juttu. Kirjasto on laaja, laajenee koko ajan ja sitten on vielä ulkopuolisten tekemät kirjastot. Avustukset auttavat jos tietää mitä etsii. Mutta jos ei tiedä, niin hakuammunnaksi menee. Ei aua muuta kuin kokeilla tyyliin googlesta: java copy string. Ja siten lueskella kirjoja ja selailla luokkahierarkioita. Minuakin masensi Javssa eniten alkuun juuri tuo avuttomuuden tunne tuon tavaramäärän edessä. Lisäksi esimerkit niiden käytöstä yleensä puuttuvat tai ovat kelvottomia, jolloin ei auta muuta kuin pienillä leikkipääohjelmilla kokeilla jonkin luokan toimintaa ja opetella sillä tavalla.
    • Google hakua voi tehostaa tässä esimerkiksi hakemalla vain JDK 1.6 dokumentaatiosta.

Attribuutit

  • Kun kysytään olio attribuutteja esim. loopissa ja jos isäolio ei sisällä ko. attribuuttia niin miten menetellään ettei tule exceptionia?
    • Tässä on jokin terminologiaongelma, koska Javassa luokka määrää mitä attribuutteja oliossa tulee olemaan ja silloin ne aina ovat. Muuten tulee jo käännösvirhe. Jos kyseessä oli esim. siitä, että
        luokassa Luokka on esitelty attribuutti
          String nimi;
        ja sitten viitataan kutsupuolella
          Luokka olio = new Luokka()
          String munnimi = olio.nimi; 
      
      niin rikoshan on jo tapahtunut, koska attribuutteihin EI SAA koskaan viitata. Jos nimeen viitataan luokan sisällä eikä tiedetä että onko nimi alustettu, niin silloin voidaan aina testata
         if ( this.nimi != null ) ... homia jos nimi on luotu ...
         else ... hommia jos nimeä ei ole luotu ... 
      
      Pitää kuitenkin muistaa että int ja double yms. -tyyppiset attribuutit ovat aina olemassa ja alustettuja vähintään 0:lla.
  • this.jotakin? Yms käyttö konstruktorissa (selvinnee kun lukee monistetta)?
    • itse asiassa ei liity konstruktoriin muten kuin että tähänastisissa esimerkeissä on tosiaan tainnut esiintyä (pitemmän aikaa, käväissyt on :-) vain konstruktorissa. Itseviitteellä (this) viitataan omiin attribuutteihin ja metodeihin. Sitä saa käyttää aina jos haluaa, mutta silloin sitä on pakko käyttää kun muuten ei olisi selvää mistä on kyse. Jos viitettä ei käytä ja kirjoittaa vaikka h, niin jos ei ole muuta h:ta näkyvillä, niin this.h ja h ovat sama asia. Mutta jos on näkyvillä lokaali h, niin silloin pelkkä h tarkoittaa sitä lokaali h:ta. this.h on aina oma attribuutti nimeltä h.
         public class Luokka {
            int h;
            public void metodi(int h) {
               h = h + 2;      /// lokaali muuttuja h kasvaa 2:lla
               this.h = h +2 ; /// attribuutti h on lokaalimuuttuja h+2
            }
         }
      
    • Mutta this() liittyykin konstruktoriin ja tarkoittaa, että kutsutaan saman luokan parametritonta konstruktoria. Ja toki voi olla this(parameteja) jolla kutsutaan ko. parametrilistalla varustettua konstruktoria. Tällaisen rivin tulee olla konstruktorin ensimmäinen rivi.
    • Lue lisää vaikka java_constructor_tutorialista (jossa tosin this.jotakin on unohdettu :-)
  • Oletusmuodostajan ja muodostajien "best practices" ja attribuuttien alustus?
    • Oletusmuodostaja kirjoitetaan jos sellainen oikeasti tarvitaan. Usein jopa sellaista ei haluta. Muuten muodostajan tehtävä on sellainen, että sen "kutsun" jälkeen olio on täysin käytettävissä ilman että dokumenteissa käsketään kutsumaan sitä ja tätä ennen käyttöä. Jos muodostajassa ei kaikkea saada alustettua, niin olion tilaksi pitää jäädä sellainen ettei sitä voi käyttää väärin.
  • Kannattaako oliolle toteuttaa privaatit setter-metodit attribuuttien alustamiseksi ja arvojen tarkistamiseksi?
    • Oikein kannatettava ajatus. Mitä harvemmassa kohti ohjelmaa viitataan attribuutteihin, sitä luotettavampi ja helpommin muutettavissa ohjelma on. Javaan sisältyy pieniä ongelmia jos muodostajassa kutsutaan metodia, joka ei ole final. Graaafisissa olioissa settereiden tehtävä on lisäksi tehdä oliolle visuaalinen muutos. Esimerkiksi jos jossakin kuvio-oliossa on attribuutti x, niin kuvio.setX(30); asettaa sisäisen koordinaatin ja samalla siirtää kuvion toiseen paikkaan. Toki kannattaa miettiä silti että onko sitenkin parempi, että olisi vain metodi kuvio.siirra(30,20);
    • Yleensä jos tekee mieli tehdä set/get-metodeja oliolle, privaatteja tai julkisia, kannattaa pysähtyä pohtimaan asioita uusiksi. Nuo set/get-metodit ovat yleensä paha haju, joka lemuaa silloin, kun olion yhtä tärkeintä ideaa, tiedon (ja toteutuksen) piilotusta, yritetään rikkoa. Eli esimerkinomaisesti, jos set/get-metodit mahdollistavat siirra-metodin toiminnan tekemisen muualla kuin siirra-metodissa, on set/get-metodit parempi hävittää, sekä kyseinen toiminta siirtää olion metodiksi. --ji
  • Kannattaako attribuutit alustaa heti määriteltäessä vai oletusmuodostajassa?
    • Jos varman päälle haluaa pelata, niin silloin heti määriteltäessä. Monimutkaisissa oliotapauksissa saattaa tällöin tulla tilanteita, joissa luodaan turhia olioita ensin attribuutin alustuslauseessa ja sitten vielä uudestaan muodostajassa. Silloin kannattaa vakavasti miettiä miten tekee. Debuggerilla kannattaa joskus mennä koodin suoritusta läpi ja miettiä että tekeekö koodi turhia olioita.
  • Jos minulla on kaksi eri luokkaa Luokka1 ja Luokka2 ja niissä attribuutit:
      class Luokka1 {
        private Luokka2 luokka2 = new Luokka2();
      }
    
      class Luokka2 {
        private Luokka1 luokka1 = new Luokka1();
      }
    
      public static void main(String[] args) {
         Luokka1 luokka1 = new Luokka1();
      }
    
    miksi ohjelmani jäi looppiin alustamaan näitä olioita?
    • Tuossa näkee ongelmat oikeastaan aika helposti siitä, että tuota koodia ei voi kirjoittaa niin, että esimerkiksi yläpuolella olisi kaikki mitä joku tarvitsee. Varsinainen syyhän tuossa on se, että pääohjelmassa luokka1-olion luomiseksi pitää kutsua Luokka1:n muodostajaa joka ensin kutsuu jokaisen attribuutin alustajaa, eli siis tässä tapauksessa luo uuden Luokka2-olion. Sen luomiseksi pitää taas kutsua Luokka2:n muodostajaa joka ennen kutsua alustaa luokka1-viitteen luomalla siihen uuden Luokka1-tyyppisen olion. Jonka alustamiseksi taas on...
    • Suosittelen että tuon koodin tuosta kirjoittaa ja ajaa debuggerissa.
    • Vaikka luokissa ei ole itse kirjoitettua muodostajaa on niissä (ja vain siitä syystä että itsekirjoitettuja muodostajia ei ole) automaattisesti oletusmuodostaja joka pitää huolen että attribuuttien alustajia kutsutaan.

Miksi ei iffiä

  • Miksi if-lausetta tulisi välttää?
    • Tekee ohjelman ylläpidon monimutkaiseksi. Holtiton if-lauseiden käyttö lähes mahdottomaksi. Aliohjelman testattavien kombinaatioiden määrä nousee suhteessa if-lauseiden määrään. Useimmiten taulukon ja/tai polymorfismin avulla saa helpommin ylläpidettävän ja jopa dynaamisesti muuttuvan ratkaisun.
    • Toki iffiä on pakko käyttää jonkin verran, mutta jos jokaista iffiä kirjoittaessa oppisi miettimään, että onko parempia vaihtoehtoja, niin se voi parantaa koodin tasoa. Vertaa esim. alkudemojen 6+ => 6.25 erilaiset ratkaisut ja niiden ylläpidettävyys.
    • Ei sitä iffiä juuri mihinkään tarvitse oliopuolella, kuten ei muitakaan ehto- tai silmukkalauseita. Samat asiat voi tehdä polymorfismilla ja perinnällä (rajapinnoilla). Hyvä harjoitus tähän on valita joku demotehtävä tai harjoitustyön osa ja kirjoittaa se niin, ettei käytä yhtään ehtolausetta. (Joskus on silti mukava kirjoitella, ihan vaikka vaan laiskuuksissaan, ehto- ja silmukkalauseita java-ohjelmiinkin...) --ji

Mikä on paketti

  • Mikä on paketti ja miten sellaisen voi tehdä itse?
    • Javassa paketti on luokkia ryhmittelevä rakenne. Monessa java-toteutuksessa se vastaa tiedostojärjestelmän hakemistoa. Näin ei kuitenkaan ole pakko olla. (Luokankaan ei javassa tarvitse olla tiedosto, vaikka näin yleensä onkin.) --ji
    • Yksinkertaisimmillaan paketti on alihakemisto suhteessa "projektin" hakemistoon. Paketin voi tehdä ihan normaalilla tavalla millä alihakemisto käytöjärjestelmässä tehdään. Eclipsessä myös projektin tai paketin päällä hiiren oikeata ja New/Package?. Java tiedostossa kirjoitetaan tiedoston alkuun vastaavasti package alihakemistonnimi; Paketin ansiosta Java-luokkia voidaan käyttää ristiin eri projektien välillä. Esim. testit kirjoitetaan yleensä vaikka test-nimiseen pakettiin itse testattavan luokkaan nähden. Mutta jos testattava luokka ei ole paketissa, ei siihen voida viitata testiluokasta. Eli käytännössä testien kanssa on pakko käyttää paketteja.
    • Ja paketit voivat olla hierarkisia kuten alihakemistotkin.
    • Pakettien oikea tarkoitus on tarjota jokaiselle oma "nimiavaruus", minkä ansiosta toisen tekijän Elain ei mene sekaisin toisen tekijän Elain-luokan kanssa. Siksi esim. kurssin aliohjelmakirjaston paketti on hierarkinen:
      fi.jyu.mit.ohj2  (Suomi, Jyväskylän yliopisto, tietotekniikan laitos, Ohj2-kurssi)
      
    • Periaatteessa paketeissa oleviin "vekottimiin" pitäisi aina viitata koko pakettinimellä, esimerkiksi:
      String viiva = fi.jyu.mit.ohj2.Mjonot.tayta("-",20);
      
      mutta kirjoittamisen vähentämiseksi tätä voidaan auttaa import-lausella:
      import fi.jyu.mit.ohj2.Mjonot;
      ... 
      String viiva = Mjonot.tayta("-",20);
      
      tai 
      import fi.jyu.mit.ohj2.*;
      ... 
      String viiva = Mjonot.tayta("-",20);
      
      tai jopa
      
      import static fi.jyu.mit.ohj2.Mjonot;
      ... 
      String viiva = tayta("-",20);
      

Testaaminen

  • Miksi ohjelmat pitää testata JUnitilla tai ComTestillä? Eikö normaalisti toimiva ohjelma riitä?
    • Mikä on normaalisti toimiva ohjelma! Jos on pääohjelma, joka kutsuu vaikka karkausvuosi-aliohjelmaa käyttäjän syötteellä, niin milloin se on toimiva! Ihminen ei jaksa testata kaikkia vaihtoehtoja. Ehkä ekalle kertaa, mutta sitten kun ohjelman johonkin osaan tehdään muutos, niin sitten ei muutoksen jälkeen jaksetakaan testata enää kaikkia vaihtoehtoja. Yleensä laiskuuksissaan testataan vain muutoksen kohteena ollut osa. Esimerkissä vaikka 100 jaolliset vuosituhannet. Ja korjaus onkin rikkonut 4:llä jaolliset vuodet eikä tätä huomata. Automaattinen testi varmistaa että aina ajetaan "määritysten" mukaiset testitapaukset ja korjaus yhdessä kohti ei riko jo kerran toiminutta. Lisäksi JUnit ja ComTest on suunniteltu ajattelun apuvälineeksi (TDD=Test Driven Development), jolloin valmiiksi testitapausten avulla voidaan miettiä mitä pitää pystyä tekemään missäkin tapauksessa ja miten asia testataan. Oikeaoppisesti tehtynä esim. ComTest-testi kirjoitetaan ennen kuin testattavaa aliohjelmaa toteutetaan ja sitten se saakin epäonnistua ja aliohjelmaa korjataan kunnes kaikki suunnitellut testit menevät läpi.
    • Jos kysymys koski sitä, että miksei alkukurssin tapainen automaattisesti testaava pääohjelma riitä, niin silloin: se on hyvin likellä samaa kuin ComTest tai JUnit (jota ComTest toki tuottaa), mutta se jättää lopputuoteohjelmaan turhaa koodia.

Materiaalia

  • Luennoilla voisi aina muistutella kun harkkatyön seuraava deadline lähestyy, ettei pääse vahingossa keneltäkään unohtumaan?
    • Taidan tehdä tuosta ryhmän ja laittaa Korppiin jokaisella tapahtuman. Ne jotka synkronoivat kalenteriaan voivat sitten muuttaa nuo hälytyksiksi :-)

Ilman hiirtä

  • Onko hiirettömästä koneenkäytöstä ohjeita/opasta jossakin? On vaikea keksiä/kokeilla kaikkea minkä haluaisi osata.
  • Miten esim. voi valita auki olevan ikkunan aktiiviseksi jos on useampia ikkunoita auki?
    • Alt pohjaan ja Tabilla painelee kunnes haluttu ikkuna on kohdalla.
  • Tai miten pääsee joihinkin kenttiiin ilman hiirtä, jos tabilla ei pääse?
    • Tuo on hankalaa jos tab ei toimi. Joskus kenttien edessä olevat sanojen kirjaimet on alleviivattu ja silloin Alt-kirjain vie kenttään.
    • Eclipsessä näppäimet löytää: Window/Preferences/General/Keys? ja noitahan voi itse muuttaa.
    • Menuissa lähes poikkeuksestta Alt pohjaan, niin menuista kirjain alleviivautuu ja sitten alleviivatun näppäimen valitseminen suorittaa toiminnon. Esim. mulla sormet tekevät Alt-F S ennen kuin ehdin ajatellakaan jos kirjoittaminen hetkeksi pysähtyy.

Komentorivi

  • Onko komentorivikirjaa olemassa? Kirjoittamalla komentoriville help jne ei saa tarpeeksi tietoa komentojen käytöstä ja netistä ei ole vielä löytynyt kaikkea?
    • Kirjoja varmaan on. Ennen suosittuja olivat Petteri Järvisen DOS-oppaat. Olethan nuo MS:n sivut katsonut! Tuo sama taitaa löytyä itse Windowsin Helpeistäkin: Start/Help? and Support ja kirjoittaa hakusanaksi: "Command-line reference".
    • Avoimen appron kursseillakin demoissa ja luennoilla on asiaa. Myös tuo avoimen Komentojonot luku on katsomisen väärtti.

Termit jotka liittyvät ohjelmointiin

  • Missä olisi lueteltu kaikki ohjelmointiin liittyvät termit (listamaisesti, että ne voisi opetella, että saisi oikeat sanat ja käsitteet haltuun tehokkaamman kommunikoinnin mahdollistamiseksi)?

Mitä pitäisi osata helmikuun alussa

  • Poikkeusten käsittely (try-catch-finally) olioiden sisällä, metodin heittämät poikkeukset?
  • Joko pitäisi osata poikkeuksien hallinta? Käsitelläänkö sitä kurssille?
    • Ei tarvitse vielä kovin syvällisesti. Se mitä olemassa olevissa esimerkeissä on ollut. Poikkeuksia käsitellään vielä ja aikanaan omaan harkkaankin tehdään omia poikkeusluokkia.
  • Halusin kertauksen String ja Stringbuffer -eroista?
    • String silloin kun jonon sisältöä ei haluta muuttaa.
    • Stringbuffer silloin kun sisältöä pitää muuttaa.
    • Koitetaan muistaa kertoilla luennoilla sopivissa asiayhteyksissä lisää.
    • Katso vaikka: http://www.yoda.arachsys.com/java/strings.html
  • Rajapinnan käsite hieman epäselvä?
    • Saa toki vielä ollakin, koska sitä ei ole kunnon esimerkein käsitelty.
  • Array list, häh? Mites se meni, mikäs se oli?
    • Tulee helmi-maaliskuun vaihteessa varsin tarkasti (kunhan itse keksimme sen tarpeen :-)
  • Parannettu for-silmukka?
    • Tulee maaliskuun alussa.
  • Miksei input- sekä outputstream olioita ole esitelty luennolla? Mitä näillä voidaan tehdä?
    • Otetaan myöhemmin tarkemmin. Esimerkiksi se System.out on yksi ilmentymä OutputStreamin kaltaisesta oliosta. Javassa vaan on hankalasti PrintStream ja OutputStream ja niistä melkoinen määrä jälkeläisiä, jotta koko IO ei ole kovin yksinkertainen asia. Perusidea on kuitenkin siinä, että kun operoidaan tarpeeksi abstraktilla tasolla olevalla tietovirralla, niin polymorfismin ansiosta konkreettinen virta voi olla melkein mikä tahansa System.out:ista merkkijonotietovirtaan tai WWW-sivulle tulevaan tietovirtaan. Omista tulostavista aliohjelmista kannattaa tehdä usein sellaisia, että niille tuodaan parametrina se tietovirta. Katso esimerkiksi luentomonisteesta 8.5.8 Aliohjelmat tulostavat harvoin. Monipuoliset mahdollisuudet tekevät aina asiat hieman vaikeammiksi. Mutta noiden tietovirtojen ansiosta voidaan esimerkiksi testeissä suunnata syöttö ja tulostus uudelleen: Demo 4, Henkilo.java ja kysy.metodin testi

Ohjeet

  • Voisiko nettisivujen ComTest-ohjeita selventää (selkeämmät ohjeet asennukseen jne.)?
    • En tuota osaa juuri paremmin tehdä: ohj2ComTest. Nuo ovat Wiki-sivuja ja toivon että joku paremmin osaava selventäisi.
  • Voiko enää juuri vähän ennen tenttiä päättää, että haluaisinkin jättää välikokeen tekemättä jos on vastoin odotuksiaan saanut tehtyä 105% demoista?
    • Ei, se päätös piti tehdä heti kurssin alussa. Mutta jos tekee 105% itsenäisesti, niin on 6 demopistettä plakkarissa ja osaamista niin paljon että se 17 pistettä on välikokeesta ihan varma.
  • Pöytätestausta taas johonkin demoon?
    • Tulee ennen välikoetta oleviin demohin.

Jatkokurssit

  • Milloin pitää ilmoittautua C++ ja JSP-osioon?
    • Viimeistään muutamia päiviä ennen kurssin alkua