Muutettu viimeksi 29.3.2016 / Sivu luotu 9.4.2010 / [oppikirjan esimerkit] / [Scala]
Sivun sisältöä:
Olio-ohjelmoinnissa luokkia rakennellaan perimällä muita luokkia (inheritance), asettamalla muiden luokkien ilmentymiä luokan jäseniksi (composition) ja ohjelmoimalla luokkiin omia ominaisuuksia, jotka täydentävät tai muuten muuttavat perittyjä ominaisuuksia.
Scalan olio-ohjelmointitekniikat muistuttavat kovasti Javan
vastaavia; tärkein lisäys ovat piirretyypit, "traitit",
jotka tavallaan ovat rajoitettua moniperintää.
Oikeastaan jo Javan rajapintaluokat (interface) ovat
moniperintää vieläkin rajoitetumpana: Vain tyyppi peritään,
ei edes osatoteutusta.
Piirretyypit esitellään omassa luvussaan. Tässä luvussa käydään tiiviisti läpi Scalan "javamaiset" periytymistekniikat.
class Yli {
private var a = 10
def setA(a: Int) {this.a = a;}
def getA = a
override def toString = "Yli-olion a on " + a
}
class Ali extends Yli {
private var b = 100
def setB(b: Int) {this.b = b;}
def getB = b
override def toString = "Ali-olion b on " + b
}
val x = new Yli
println(x); // Yli-olion a on 10
x.setA(123)
println(x) // Yli-olion a on 123
val y = new Ali()
println(y) // Ali-olion b on 100
y.setB(321)
println(y) // Ali-olion b on 321
println("Alista näkyy Ylin a: " + y.getA) // Ali-oliossa on siis myös a: 10
y.setA(999) // ja sitä voi myös muuttaa a: 999
println("Ja sitä voi muuttaa a = " + y.getA)
Abstraktin luokan tavanomainen tehtävä on määritellä tyyppi, johon kuuluvia eri aliluokkien ilmentymiä voidaan sitten käsitellä tuon abstraktin luokan tyyppisissä muuttujissa, parametreissa, .. (Jos tämä ei kuulosta tutulta, on paras pikimmiten kerrata peruskurssien asiat! ;-)
Huom: Scalassa tähän tehtävään on tyypillisempää ja tyylikkäämpää kuitenkin käyttää piirretyyppiä (trait). Siitä lisää seuraavassa luvussa.
Kuten Javassa Scalan abstrakti luokka ilmaistaan määreellä abstract. Scalassa abstrakteille metodeille tuota määrettä ei kuitenkaan anneta:
Laaditaan 1960-luvun F1-maailmaan liittyvä esimerkki vanhalta Java-kurssilta muokattuna:
abstract class Moottori {
def annaKierrosluku(): Double // vain metodin otsikko!
def asetaPolttoaineensyottomaara(maara: Double): Unit
// ... Täällä voisi vallan mainiosti olla myos ei-abstrakteja metodeita!
// ... Jopa ja nimenomaan myös sellaisia, jotka kutsuvat abstrakteja metodeita!
}
Tässä siis vain esitetään vaatimus, että jokaisen Moottori-tyyppisen
olion pitää omata nuo metodit.
Ja erityisesti Moottori siis kelpaa
muuttujan, parametrin, funktion, ..., tyypiksi.
Ohjelmoidaan sitten luokka, joka sisältää abstraktin Moottori-tyyppisen kentän. Idea (kuten pitäisi olla tuttua!) on siis siinä, että voidaan ohjelmoida välineitä, jotka eivät ole riippuvaisia minkään erityisen moottorin ominaisuuksista. Yleiskäyttöisyyttä, koodin uudelleenkäyttöä, varmistettua riippumattomuutta...
class Auto(m: Moottori) { // Moottori on abstrakti luokka!
// rakennellaan loputkin autosta ...
def mitenLujaaMennaan() = {
// nopeus riippuu tavalla tai toisella kierrosluvusta:
m.annaKierrosluku()/30
}
def kaasuta(bensaa: Double) {
m.asetaPolttoaineensyottomaara(bensaa)
// ...
}
// ties mitä muita metodeita ...
}
Abstraktista luokasta ei tunnetusti voi luoda ilmentymiä!
Tarvitaan siis jokin abstraktin Moottori-luokan
ei-abstrakti aliluokka, jotta Auto-ilmentymiä
voitaisiin luoda.
class Cosworth extends Moottori {
private var kierrosluku = 0.0
// muut tietorakenteet ...
def annaKierrosluku() = kierrosluku // getteri
def asetaPolttoaineensyottomaara(maara: Double) {
kierrosluku =
if (maara < 0) 0.0
else if (maara > 100)
9300.0
else
(maara/100)*9300 // tms...
}
// muita aksessoreita ...
}
Ja johan alkaa syntyä kilpa-autoja:
val brrrmmm = new Cosworth() // "oikea moottori", joka val lotus49 = new Auto(brrrmmm) // kelpaa auton luontiin lotus49.kaasuta(96) println(lotus49.mitenLujaaMennaan()) // 297.6 lotus49.kaasuta(-23); println(lotus49.mitenLujaaMennaan()) // 0.0 lotus49.kaasuta(1100) println(lotus49.mitenLujaaMennaan()) // 310.0 // myös tyypillinen tekniikka: val brabham = new Auto(new Cosworth()) brabham.kaasuta(99) println(brabham.mitenLujaaMennaan()) // 306.9Vastaavalla tavalla voitaisiin luoda ja käyttää Auto-olioita milloin milläkin moottorilla... Auton moottoriksi kelpaa mikä tahansa olio, jonka luokka on Moottori-luokan ei-abstrakti aliluokka!
Terminologinen huomautus: Ohjelmointikielistä puhuttaessa esitteleminen (declare) ja määritteleminen (define) tarkoittavat erityisiä asioita: Nimet eli tunnukset esitellään ja nimien eli tunnuksien merkitys määritellään. Yllä luokka Moottori vain esitteli tunnuksen annaKierrosluku. Luokka Cosworth sitten myöskin esittelyn lisäksi määritteli tuon tunnuksen omalla tavallaan.
Edellä kirjoitettiin tyhjät sulkeet näkyviin:
def annaKierrosluku(): Double // abstraktina ... m.annaKierrosluku() // käytössä ... def annaKierrosluku() = kierrosluku // toteutuksessaSulkeet voi myös jättää pois
def annaKierrosluku: Double // abstraktina ... m.annaKierrosluku // käytössä ... def annaKierrosluku = kierrosluku // toteutuksessaKumpikin tapa kelpaa kääntäjälle, mutta kaikki sekoitukset eivät. [Englanniksi (vai Scala-englanniksi?) sanapari on "parameterless method" ja "empty-paren method".]
"Tapana on", "tyyliin kuuluu", kirjoittaa tyhjä parametrilista näkyviin silloin, kun metodi muuttaa olion kenttiä, kun metodi siis on "setteri" tai sillä on muita sivuvaikutuksia. Tyhjä parametrilista on tapana kirjoittaa myös silloin, kun kyseessä on "getteri", jonka arvo riippuu muuttuvista kentistä.
Mutta sivuvaikutukseton "getteri" immutaabeleista kentistä on tyylin mukaista ohjelmoida ilman tyhjiä sulkeita.
Tässä tyylittelyssä ei ole todellakaan kyse pelkästä "ohjelmointiestetiikasta"! Kun parametriton metodi kirjoitetaan ilman tyhjiä sulkeita, tarvittaessa metodi voidaan korvata kentällä tyyliin;
// metodit height ja width
abstract class Element {
def contents: Array[String]
def height: Int = contents.length
def width: Int = if (height == 0) 0 else contents(0).length
}
// kentät height ja width
abstract class Element {
def contents: Array[String]
val height = contents.length
val width = if (height == 0) 0 else contents(0).length
}
Tämän luokan käyttäjä (aliluokan ohjelmoija tai aliluokan
ilmentymiä käyttävä ohjelmoija) viittaa nimiin height
ja width ihan samalla tavalla riippumatta siitä, ovatko
ne metodeita vai kenttiä!
Yksi tärkeä ero metodi- ja kenttäratkaisussa on se, että kenttä vie tilaa ja metodin kutsu puolestaan laskenta-aikaa. Valinta on luokan toteuttajan. Ja oleellista on, että tämä valinta on kapseloitu tuohon luokkaan! Sovelluksen kannalta toiminnallisuus on sama.
"Eikä tässä vielä kaikki": Vaikka abstrakti luokka määrittelisi parametrittoman metodin, toteutusluokka voi toteuttaa sen kenttänä!
abstract class Moottori {
def annaKierrosluku: Double
def asetaPolttoaineensyottomaara(maara: Double): Unit
}
class Auto(m: Moottori) { // Moottori on abstrakti luokka!
// rakennellaan loputkin autosta ...
def mitenLujaaMennaan() = {
// nopeus riippuu tavalla tai toisella kierrosluvusta:
m.annaKierrosluku/30
}
def kaasuta(bensaa: Double) {
m.asetaPolttoaineensyottomaara(bensaa)
}
}
class TasaKone extends Moottori {
val annaKierrosluku = 1000.0 // vakiogetteri
def asetaPolttoaineensyottomaara(maara: Double) { }
}
val surrur = new TasaKone() // "oikea moottori", joka
val trabi = new Auto(surrur) // kelpaa auton luontiin
trabi.kaasuta(96)
println(trabi.mitenLujaaMennaan()) // 33.333333333333336
trabi.kaasuta(-23);
println(trabi.mitenLujaaMennaan()) // 33.333333333333336
trabi.kaasuta(1100)
println(trabi.mitenLujaaMennaan()) // 33.333333333333336
Huom: Perittyä kenttää ei voi korvata metodilla.
Kuten nähtiin, Scalassa kuitenkin myös kentät voivat korvata metodeja. Tästä seuraa tärkeä ero Javaan: kenttien ja metodien nimet kuuluvat samaan nimiavaruuteen, joten niiltä vaaditaan yksikäsitteisyyttä.
Ja todellakin, kenttä voi korvata perityn metodin! Mutta ei toisin päin...
Javassa samannimisyys sallitaan kentille, metodeille, luokille (eli tyypeille), pakkauksille ja osoitteille (nimetyille lauseille break- ja contunue-lauseita varten). Scalassa tällaisia "nimiavaruuksia" on vain kaksi: arvot (kentät, metodit, pakkaukset, ainokaiset) ja tyypit (luokkien ja piirretyyppien (trait) nimet).
Myös määreet private, protected, override ja final ovat käytettävissä. Javasta poiketen Scalan protected tuottaa vain aliluokkanäkyvyyden, ei pakkausnäkyvyyttä! Ja hyvä niin. Määre final Javan tapaan estää kentän (tai metodin) korvaamisen aliluokassa.
Perityn kentän voi korvata myös konstruktorin parametrilistassa eli luokkaparametreissa.
class Cat {
val dangerous = false
}
class Tiger( override val dangerous: Boolean,
private var age: Int
) extends Cat
Tämä (lähes) vastaa sitä, että kirjoitettaisiin:
class Tiger(param1: Boolean, param2: Int) extends Cat {
override val dangerous = param1
private var age = param2
}
Tässä tosin tilaa varataan myös privaattikentille
param1 ja param2.
class Piste(private var x: Int, private var y: Int) {
def this() = this(0, 0)
def siirry(dx: Int, dy: Int) {x += dx; y += dy;}
override def toString = "("+x+","+y+")"
}
val a = new Piste()
val b = new Piste(7, 14)
println(a) // (0,0)
println(b) // (7,14)
a.siirry(2, 3)
b.siirry(4, 5)
println(a) // (2,3)
println(b) // (11,19)
Laaditaan sitten tälle luokalle aliluokkana värillinen piste:
class VariPiste( x: Int, y: Int, private var vari: Int
) extends Piste(x, y) {
// HUOM: yliluokan konstruktorille annetaan parametrit!
def this() = this(0, 0, 0)
def this(vari: Int) = this(0, 0, vari)
//-- lisämetodi:
def uusiVari(vari: Int) {this.vari = vari}
override def toString = super.toString + " väri: " + vari
// HUOM: super-viittaus korvattuun perittyyn metodiin!
}
val c = new VariPiste()
val d = new VariPiste(7)
val e = new VariPiste(4,5,9)
println(c) // (0,0) väri: 0
println(d) // (0,0) väri: 7
println(e) // (4,5) väri: 9
e.siirry(1, 1) // yliluokan operaation käyttö!
println(e) // (5,6) väri: 9
e.uusiVari(14) // oman operaation käyttö
println(e) // (5,6) väri: 14
Esimerkki:
abstract class Yli {
val a = 1
private val b = 2
def c = 3 // metodeita
def d: Int // abstrakti
}
class Ali extends Yli {
override val a = 10 // override pakollinen
private val b = 20 // override kielletty
override def c = 30 // override pakollinen
def d = 40 // override sallittu muttei pakollinen
val e = 50 // override kielletty
}
Sitten paljastuu, ettei
asia kuitenkaan ole edes noin "suoraviivainen":
abstract class Yli {
def a = 1
val b = 2
var c = 3
val d = 4
}
class Ali extends Yli {
override def a = 10 + super.a // korvattu metodi, viittaus korvattuun metodiin
override val b = 20 // ok
// val xx = 10 + super.b // error: super may be not be used on value b
// override var c = 30 // variable c cannot override a mutable variable
// val yy = 10 + super.c // error: super may be not be used on variable c
// override var d = 40 // error overriding value d in class Yli of type Int;
// variable d needs to be a stable, immutable value
}
val x = new Ali
println(x.a) // 11
println(x.b) // 20
Scalan override ei vaikuta ihan yhtä tyylikkäältä kuin kielen monet muut ominaisuudet...
"Arton polymorfismisääntöjä":
Olkoon TyyppiB luokka, joka on luokan TyyppiA välitön tai välillinen aliluokka. Ja olkoon muuttuja x tuon yliluokan tyyppiä: x: TyyppiA
Tällaisen muuttujan arvoksi voi sijoittaa viitteen mihin tahansa olioon, joka on tyyppiä TyyppiA. Koska "jokainen kissa on eläin" eli aliluokan jokainen ilmentymä on myös yliluokan tyyppiä, on luvallista sijoittaa
x = new TyyppiB()"Aksessoidaan muuttujaa" tuttuun tyyliin: x.met()
val a: VariPiste = new VariPiste(7) val b: Piste = a val c: Any = a println(a) // (0,0) väri: 7 println(b) // (0,0) väri: 7 println(c) // (0,0) väri: 7Siis olion tyyppi – ei muuttujan tyyppi – määrää, mikä versio toString-metodista valitaan.