Ohjelmointitekniikka (Java) - Kevät 2008 - Kurssikoe 28.2.
Arvosteluperusteet
25.3.2008 Tuomas Blom


1. Poikkeukset

a) Poikkeusten luokkahierarkia (max 3 pistettä)
    
    - 1p: Luokkahierarkia piirretty/selitetty oikein
    - 1p: Eri luokkien roolit selitetty riittävän hyvin
    - 1p: Selvitetty, miten tarkistetut ja tarkistamattomat poikkeukset ovat erilaisia käännettäessä
      (checkedit täytyy käsitellä tai julistaa heitettäviksi)
      
b) Poikkeusten heittäminen (max 3 pistettä)

    - 1p: Tarkistettu poikkeus, kun tilanteesta voidaan yrittää toipua
      (poikkeuksellinen, mutta odotettavissa oleva tilanne)
    - 1p: Tarkistamaton poikkeus, kun kyseessä on ohjelmointivirhe
      (oliota/metodia käytetty väärin tms.)
    - 1p: Omat poikkeukset Exceptionin tai RuntimeExceptionin aliluokkina

(Asioita ei tarvinnut selittää välttämättä juuri a)- tai b)-vastauksessa,
 kunhan kävi tehtävästi ilmi)

 
2. Kokoelmat ja geneerisyys

a) Collections Frameworkin päätyypit (max 4 pistettä)

    - 2p: Jakautuu päätyyppeihin Collection ja Map (1p jos vain toinen oikein)
      (pisteen sai myös, jos luokkia ei nimennyt, mutta määritteli jakautuvan
      "yksittäisten arvojen kokoelmiin ja avain-arvo -parien kokoelmiin" tjms.)
    - 1p: Collectioneissa yksittäisiä arvoja, Mapeissa avain-arvo -pareja
    - 1p: Mapin avainten ja arvojen joukot ovat Collectioneja
    - 1p: Mapia ei voi iteroida suoraan, kaikkia Collectioneja voi

b) Abstraktit kokoelmaluokat (max 4 pistettä)

    - 1p: Tarkoituksena helpottaa omien kokoelmaluokkien toteuttamista
    - max 3 pistettä lopusta selityksestä:
        - Abstraktin kokoelman aliluokan riittää toteuttaa vain muutama metodi
        - Muut rajapinnan metodit peritään abstraktilta luokalta
        - Yläluokka toteuttaa muut metodit abstraktien metodien avulla
        - ...mutta jotkut metodit voivat vain heittää poikkeuksen
        - Mikään ei kuitenkaan estä aliluokkaa toteuttamasta muitakin metodeita
        
c) Luokka Pair (max 4 pistettä)

    - 1 piste kustakin:
        - Pair EI OLE Pair:in aliluokka
        - Pair[] ON myös tyyppiä Object[]
        - Pair[] EI OLE myös tyyppiä Pair[]
    - 1 piste perustelusta. Perusteluksi kävi jokin seuraavista:
        - Ymmärsi sanoa maagisen sanan "tyyppiturvallisuus" - ensimmäisessä
          ja viimeisessä tapauksessa on pohjimmiltaan kyse siitä
        - osasi perustella ensimmäistä tapausta sillä, että käännöksessä tieto
          tyyppiparametreista menetetään, ja käännöksen jälkeen molemmat ovat
          raakatyyppiä Pair (vailla tarkempaa selitystä pelkkä "ne ovat eri
          tavalla käytettyjä ilmentymiä samasta luokasta" ei riittänyt)
        - Osasi perustella viimeistä tapausta sillä, ettei geneerisistä luokista
          ole edes sallittua luoda taulukkoa (paitsi tyyppiparametrilla )


3. Säikeet ja GUI

a) Säikeiden luonti (max 4 pistettä)

    - 2p: Yksi tapa luoda säie selitetty/koodattu oikein riittävän tarkasti:
      (1 piste, jos pieniä virheitä)
        - Threadin aliluokkana: new OmaThread().start();
        - Runnable-rajapinnalla: new Thread(new OmaRunnable()).start();
        - Molemmissa tapauksissa säikeen toiminnallisuus run()-metodissa
        - Anonyymi sisäluokka ei siis kelvannut omaksi tavakseen, jos sama
          perustapa (Thread tai Runnable) oli jo selitetty
    - 1p: Jos toinenkin tapa selitetty oikein
    - 1p: Perusteltu Runnablen tarve jotenkin:
        - Javassa ei moniperintää, joten pelkkä Thread olisi turhan rajoittavaa
        - Runnable eriyttää säikeen mekanismin säikeen suorittamasta tehtävästä,
          ja useat eri säikeet voivat käyttää samaa Runnable-oliota

b) Ohjelmahahmo ("idiomi") (max 4 pistettä)

    - 1p: Idiomissa on kyse säikeen suoritussilmukasta ja sen lopetusehdoista
    - 1p: Säikeen halutaan toimivan, kunnes se saa työnsä valmiiksi tai se keskeytetään
    - 2p jos osasi perustella molemmat keskeytystarkistukset (1p jos vain toisen):
        - Jos säie on blokattuna (sleep/wait), keskeytys aiheuttaa poikkeuksen
          InterruptedException
        - Jos säie ei blokkaa, keskeytys nostaa vain lipun pystyyn, jota säikeen
          pitää tarkkailla itse (silmukan ehto !interrupted())
    - Finallyn selittämällä saattoi lähinnä kääntää epäselvän tilanteen edukseen
      (eli finallyssa on hyvä suorittaa lopetustoimet riippumatta siitä, kuinka
      silmukasta poistuttiin)
      
c) Event dispatch thread ja worker thread (max 4 pistettä)

    - 2p yleisistä kuvauksista:
        - Event dispatch thread (EDT) on graafisen käyttöliittymän tapahtumankäsittelysäie
        - Worker thread on työsäie, jolle raskas laskenta annetaan suoritettavaksi,
          jotta EDT voisi jatkaa porskuttamista
    - 2p tarkennuksista:
        - Swing-komponentit eivät ole säieturvallisia, joten on "single thread rule",
          jonka mukaan GUI-elementtien tilaa saa käsitellä vain EDT:stä
        - Jos EDT:ssä tehtäisiin raskasta laskentaa, koko käyttöliittymä jumiutuisi
          laskennan ajaksi
        - Kun työsäie saa työnsä päätökseen, sen pitää antaa mahdolliset päivitykset
          käyttöliittymäkomponentteihin EDT:n tehtäväksi (metodit
          EventQueue.invokeLater(Runnable) ja EventQueue.invokeAndWait(Runnable))
          






Takaisin koesivulle.