Pelikortti ohjelmoiti Javalla
Tarmo Ronkainen
Suunnittelin tässä tavallisiin pelikortteihin perustuvaa työtä.
Seuraavat luokat onnistuin tekemään netin avulla rankasti copy&pastella:
http://koti.mbnet.fi/tarez/java/Pakka.java
-Korttipakan luonti ja sekoitus
http://koti.mbnet.fi/tarez/java/Kortti.java
-Kortin määrittely, maa ja arvo
http://koti.mbnet.fi/tarez/java/Poyta.java
-"Pelipöytä" jonne kortteja mätkitään
http://koti.mbnet.fi/tarez/java/Testi.java
-Pieni testi koko systeemistä
Tuolla tavalla voisin jatkaa työn tekemistä, mutta sitten kävikin ilmi että
homma pitäisi hoitaa tekemällä tietue (?) korttipakasta ja ohjelma pitää
koostua päämetodista/-funktiossa (main) ja yhdestä tai useammasta
alimetodista/-funktiosta.
Mitenkäs tuo tietue tehdään? Koko homma pitäisi ilmeisesti saada yhden .java
tiedoston sisään.
Apuna on ollut Petri Kiutun Java-ohjelmoiti PRO-kurssi kirja ja
kurssimonisteet. Nettiä on myös tullut selailtua muutama päivä, mutta ei ole
oikein lähtenyt homma käyntiin. Help!
A Pietu Pohjalainen
> Suunnittelin tässä tavallisiin pelikortteihin perustuvaa työtä.
> Seuraavat luokat onnistuin tekemään netin avulla rankasti copy&pastella:
> http://koti.mbnet.fi/tarez/java/Pakka.java
> -Korttipakan luonti ja sekoitus
> http://koti.mbnet.fi/tarez/java/Kortti.java
> -Kortin määrittely, maa ja arvo
> http://koti.mbnet.fi/tarez/java/Poyta.java
> -"Pelipöytä" jonne kortteja mätkitään
> http://koti.mbnet.fi/tarez/java/Testi.java
> -Pieni testi koko systeemistä
> Tuolla tavalla voisin jatkaa työn tekemistä, mutta sitten kävikin ilmi että
> homma pitäisi hoitaa tekemällä tietue (?) korttipakasta ja ohjelma pitää
> koostua päämetodista/-funktiossa (main) ja yhdestä tai useammasta
> alimetodista/-funktiosta.
Tämä kuulostaa siltä, että kurssisi opettaja on
opetellut / opetettu ohjelmoimaan proseduraalisen
ohjelmointiparadigman mukaisesti. Kun kielenä nyt sattuu olemaan
Java, jota niin olio-suuntautuneena kielenä on kehuttu, niin
olisi kovin kummallista pakottaa käyttämään proseduraalista
lähestymistä ongelman ratkaisemiseen.
Näin etenkin nyt kun ongelma on selkeästi oliomallinnuksella
saatavissa pilkottua yksinkertaisiin ja siten helposti
hahmotettaviin osiin.
> Mitenkäs tuo tietue tehdään? Koko homma pitäisi ilmeisesti saada yhden .java
> tiedoston sisään.
> Apuna on ollut Petri Kiutun Java-ohjelmoiti PRO-kurssi kirja ja
> kurssimonisteet. Nettiä on myös tullut selailtua muutama päivä, mutta ei ole
> oikein lähtenyt homma käyntiin. Help!
Mikäli javassa tarvitaan tietuetta vastaavaa rakennetta, voidaan
käyttää luokkaa, jolla on vain public-tyyppisiä attribuutteja.
Usein käytetään ns. sisäluokkia, jotta voitaisiin näyttää
myöhemmin koodia lukevalle, että suunnilleen on ymmärretty mitä
ollaan tekemässä.
class Kortti {
public int arvo;
public int maa;
}
Tai jotain tuon suuntaista. Mutta, tällä lähestymistavalla
selkeästi menetetään ne edut, joita olioita käyttämällä olet
saavuttanut.
Olisi mielenkiintoista kuulla harjoitustyön ohjaajan perustelut
proseduraalisen lähestymistavan käyttämiseen. Tämä etenkin, kun
90-luvun alusta lähtien on maailmassa kulutettu miljoonia
opetustunteja vanhojen koodareiden muuntamiseksi
olio-suuntautuneiksi -- ja nyt sitten tulevat sukupolvetkin
koulutetaan vaikeamman kaavan kautta. Perin erikoislaatuista.
/Pietu Pohjalainen
Lauri Alanko
> Olisi mielenkiintoista kuulla harjoitustyön ohjaajan perustelut
> proseduraalisen lähestymistavan käyttämiseen. Tämä etenkin, kun
> 90-luvun alusta lähtien on maailmassa kulutettu miljoonia
> opetustunteja vanhojen koodareiden muuntamiseksi
> olio-suuntautuneiksi -- ja nyt sitten tulevat sukupolvetkin
> koulutetaan vaikeamman kaavan kautta. Perin erikoislaatuista.
Yksi etu datan ja operaatioiden erillään pitämisessä on, että uusia
operaatioita on helpompi lisätä. Olio-ohjelmoinnin perusajatus on, että
ohjelman toiminnallisuus voidaan luontevasti jakaa niin, että kukin
tietotyyppi ja sen operaatiot muodostavat kiinteän kokonaisuuden,
luokan. Jos operaatioita halutaan lisätä, täytyy luokkaankin koskea.
Tämä vaatii mm., että luokan lähdekoodikin on käytettävissä.
Käytännössä C++/Java-tyylisissä oliokielissä päädytäänkin siihen, että
luokassa itsessään on vain "primitiivioperaatiot", jotka vaativat pääsyä
olioiden sisäiseen rakenteeseen, ja "apuoperaatiot", jotka on rakennettu
primitiivien päälle, ja joita voidaan tarpeen vaatiessa kirjoittaa
ilman, että kosketaan luokan toteutukseen, sitten pistetään jonnekin
muualle staattisiksi metodeiksi. Tätä tekniikkaa käytetään jopa ihan
Javan vakiokirjastoissa: java.util.Collections.
Ongelma tässä on tietysti, että nyt eri operaatioilla on erilainen
syntaksi: osa on olion omia metodeita, osa on apufunktioita, joille
annetaan olio argumenttina. Tämä eron aiheuttavat vain toteutusseikat:
jotkin operaatiot ovat "primitiivisiä", toiset taas niiden päälle
rakennettuja. Silti olion käyttäjäkin joutuu ottamaan tämän eron
huomioon, mikä rikkoo abstraktin tietotyypin periaatetta raskaasti.
Tätä ongelmaa ei tietenkään esiinny sellaisissa oliokielissä, jotka
eivät erottele funktioita ja metodeja (CLOS), tai jotka sallivat uusien
metodien lisäämisen luokan määrittelyn jälkeenkin (Smalltalk).
Lauri Alanko
l...@iki.fi
Jani Miettinen
> Tätä ongelmaa ei tietenkään esiinny sellaisissa oliokielissä,
> jotka eivät erottele funktioita ja metodeja (CLOS), tai jotka
> sallivat uusien metodien lisäämisen luokan määrittelyn
> jälkeenkin (Smalltalk).
Myös staattisia muuttujia ja attribuutteja voidaan lisäillä
jälkikäteen joissakin kielissä.
--
Mustissaan kirput kulkivat hautajaisiin.
Kateissa olleita tovereita muistettiin.
Jonne Itkonen
> Käytännössä C++/Java-tyylisissä oliokielissä päädytäänkin siihen, että
> luokassa itsessään on vain "primitiivioperaatiot", jotka vaativat pääsyä
> olioiden sisäiseen rakenteeseen, ja "apuoperaatiot", jotka on rakennettu
> primitiivien päälle, ja joita voidaan tarpeen vaatiessa kirjoittaa
> ilman, että kosketaan luokan toteutukseen, sitten pistetään jonnekin
> muualle staattisiksi metodeiksi.
Jos on tähän vaiheeseen jouduttu, kannattaa heittää suunnitelmat roskiin,
poltaa GoF-kirjansa, istua hetki hiljaa paikallaan ja aloittaa alusta. :)
> Tätä tekniikkaa käytetään jopa ihan
> Javan vakiokirjastoissa: java.util.Collections.
Niinpä näyttävät pannahiset tekevän. Miksiköhän moinen? Miksi ei tehdä
kuten C++:n iteraattoreilla, säilöillä ja algoritmeilla: Algoritmit
kirjoitetaan käyttäen iteraattoreita, jolloin samaa algoritmia voi
käyttää kaikkien niiden säilöjen kanssa, joille on olemassa algoritmin
tarvitsema iteraattori.
Liekö sitten oma tulkintani, mutta viime aikoina on alkanut näyttää sille,
että kunnollinen analyysi ja suunnittelu halutaan jättää puolitiehen juuri
käyttämällä tuollaisia temppuja, kuin yllä on kuvattu. Tehdään luokkaan
mahdollisuus määritellä dynaamisesti lisää metodeja, kun ei jakseta
asioita loppuun asti pohtia.
>> Tätä ongelmaa ei tietenkään esiinny sellaisissa oliokielissä, jotka
> eivät erottele funktioita ja metodeja (CLOS), tai ...
Onkohan tuo nyt ihan noin? Sotketkos kenties metodit, geneeriset
funktiot ja funktiot keskenään?
Jonne
Marko Taipale
news:ar35k7$7hu$1...@mordred.cc.jyu.fi:
> Lauri Alanko <l...@iki.fi> wrote:
>> Käytännössä C++/Java-tyylisissä oliokielissä päädytäänkin siihen,
>> että luokassa itsessään on vain "primitiivioperaatiot", jotka
>> vaativat pääsyä olioiden sisäiseen rakenteeseen, ja "apuoperaatiot",
>> jotka on rakennettu primitiivien päälle, ja joita voidaan tarpeen
>> vaatiessa kirjoittaa ilman, että kosketaan luokan toteutukseen,
>> sitten pistetään jonnekin muualle staattisiksi metodeiksi.
>
> Jos on tähän vaiheeseen jouduttu, kannattaa heittää suunnitelmat
> roskiin, poltaa GoF-kirjansa, istua hetki hiljaa paikallaan ja
> aloittaa alusta. :)
:D
Minusta Laurin pointti ei ole mitenkään kaikkialla sovellettavissa, enkä
usko, että Laurikaan sellaiseksi sitä tarkoitti.
>
>> Tätä tekniikkaa käytetään jopa ihan
>> Javan vakiokirjastoissa: java.util.Collections.
>
> Niinpä näyttävät pannahiset tekevän. Miksiköhän moinen?
Et ole ensimmäinen, joka kyseenalaistaa "utility class idiom":n.
Suosittelen lukemaan Joshua Bloch:n Effective Java Programming Language
Guide:sta item 3:n, joka johdattelee alkuperäisen idean lähteille.
Asiaa on pohdittu mm.:
http://saloon.javaranch.com/cgi-
bin/ubb/ultimatebb.cgi?ubb=get_topic&f=9&t=000645
(Erityisesti Michael Matola:n kommenteissa)
http://www.javaworld.com/javaworld/javaone01/j1-01-sintes2.html
Bloch on myös usein ilmoittanut olevansa käytettävissä tämän tyyppiseen
keskusteluun, joten kehoitan kysymään asiaa, joko
comp.lang.java.programmer-ryhmästä, jota hän satunnaisesti seurailee, tai
häneltä itseltään mailitse (joshua...@sun.com).
> Liekö sitten oma tulkintani, mutta viime aikoina on alkanut näyttää
> sille, että kunnollinen analyysi ja suunnittelu halutaan jättää
> puolitiehen juuri käyttämällä tuollaisia temppuja, kuin yllä on
> kuvattu. Tehdään luokkaan mahdollisuus määritellä dynaamisesti lisää
> metodeja, kun ei jakseta asioita loppuun asti pohtia.
Nähdäkseni yleiskäyttöisen APIn suunnittelua ja määrittelyä on hyvin
hankala pohtia loppuun asti. Kerran kun johonkin päätyy, niin sen kanssa on
sitten elettävä jatkossakin.
Antoisa haastattelu APIn suunnittelusta:
http://www.artima.com/intv/blochP.html
- Marko -
Lauri Alanko
Jonne Itkonen <j...@tarzan.it.jyu.fi> wrote:
> Lauri Alanko <l...@iki.fi> wrote:
> > Käytännössä C++/Java-tyylisissä oliokielissä päädytäänkin siihen, että
> > luokassa itsessään on vain "primitiivioperaatiot", jotka vaativat pääsyä
> > olioiden sisäiseen rakenteeseen, ja "apuoperaatiot", jotka on rakennettu
> > primitiivien päälle, ja joita voidaan tarpeen vaatiessa kirjoittaa
> > ilman, että kosketaan luokan toteutukseen, sitten pistetään jonnekin
> > muualle staattisiksi metodeiksi.
>
> Jos on tähän vaiheeseen jouduttu, kannattaa heittää suunnitelmat roskiin,
> poltaa GoF-kirjansa, istua hetki hiljaa paikallaan ja aloittaa alusta. :)
Voi olla vähän hankalaa, jos kuitenkin tarvitaan apuoperaatioita
sellaiseen luokkaan, jonka lähdekoodia ei kerta kaikkiaan ole
saatavilla.
> > Tätä tekniikkaa käytetään jopa ihan
> > Javan vakiokirjastoissa: java.util.Collections.
>
> Niinpä näyttävät pannahiset tekevän. Miksiköhän moinen? Miksi ei tehdä
> kuten C++:n iteraattoreilla, säilöillä ja algoritmeilla: Algoritmit
> kirjoitetaan käyttäen iteraattoreita, jolloin samaa algoritmia voi
> käyttää kaikkien niiden säilöjen kanssa, joille on olemassa algoritmin
> tarvitsema iteraattori.
Juuri noinhan java.util.Collections:in metodit onkin toteutettu.
Kysymys on vain siitä, millaisen rajapinnan kautta tuollaiset
yleiskäyttöiset operaatiot pitäisi tarjota. Onko sinulla tarjota
parempi vaihtoehto, miten java.util.Collections:in toiminnallisuus
olisi pitänyt tarjota?
> Liekö sitten oma tulkintani, mutta viime aikoina on alkanut näyttää sille,
> että kunnollinen analyysi ja suunnittelu halutaan jättää puolitiehen juuri
> käyttämällä tuollaisia temppuja, kuin yllä on kuvattu. Tehdään luokkaan
> mahdollisuus määritellä dynaamisesti lisää metodeja, kun ei jakseta
> asioita loppuun asti pohtia.
On aika vaikeaa pohtia "loppuun asti" kirjastoluokkaa, jonka on
tarkoitus olla yleiskäyttöinen. Etenkin yksinkertaisille
tietorakenteille voi tehdä lukemattomia hyödyllisiä juttuja, joiden
kaikkien pistäminen valmiiksi luokan metodeiksi paisuttaisi sitä
älyttömästi.
> >> Tätä ongelmaa ei tietenkään esiinny sellaisissa oliokielissä, jotka
> > eivät erottele funktioita ja metodeja (CLOS), tai ...
>
> Onkohan tuo nyt ihan noin? Sotketkos kenties metodit, geneeriset
> funktiot ja funktiot keskenään?
Tarkoitin, ettei erottele _syntaktisesti_ funktioiden ja metodien
kutsumista, ja metodilla tässä tarkoitan yleisesti ad hoc-polymorfista
operaatiota: se, mitä metodi itse asiassa tekee, riippuu siitä,
millaiseen olioon sitä sovelletaan. Tämä siis vastaa CLOSin geneeristä
funktiota. Tiedän kyllä, että CLOSissa "method" tarkoittaa nimenomaan
yksittäistä geneerisen funktion toteutusta tietylle luokalle.
Lauri Alanko
l...@iki.fi
Jonne Itkonen
> In article <ar35k7$7hu$1...@mordred.cc.jyu.fi>,
> Jonne Itkonen <j...@tarzan.it.jyu.fi> wrote:
>> Lauri Alanko <l...@iki.fi> wrote:
>> > Käytännössä C++/Java-tyylisissä oliokielissä päädytäänkin siihen, että
>> > luokassa itsessään on vain "primitiivioperaatiot", jotka vaativat pääsyä
>> > olioiden sisäiseen rakenteeseen, ja "apuoperaatiot", jotka on rakennettu
>> > primitiivien päälle, ja joita voidaan tarpeen vaatiessa kirjoittaa
>> > ilman, että kosketaan luokan toteutukseen, sitten pistetään jonnekin
>> > muualle staattisiksi metodeiksi.
>>
>> Jos on tähän vaiheeseen jouduttu, kannattaa heittää suunnitelmat roskiin,
>> poltaa GoF-kirjansa, istua hetki hiljaa paikallaan ja aloittaa alusta. :)
> Voi olla vähän hankalaa, jos kuitenkin tarvitaan apuoperaatioita
> sellaiseen luokkaan, jonka lähdekoodia ei kerta kaikkiaan ole
> saatavilla.
Joo, tuossa tapauksessa kenties, mutta yllä kirjoitit mielestäni, että
luokat pitäisi _suunnitella_ tuollaisiksi. Saatoinhan ymmärtää väärin...
>> > Tätä tekniikkaa käytetään jopa ihan
>> > Javan vakiokirjastoissa: java.util.Collections.
>>
>> Niinpä näyttävät pannahiset tekevän. Miksiköhän moinen? Miksi ei tehdä
>> kuten C++:n iteraattoreilla, säilöillä ja algoritmeilla: Algoritmit
>> kirjoitetaan käyttäen iteraattoreita, jolloin samaa algoritmia voi
>> käyttää kaikkien niiden säilöjen kanssa, joille on olemassa algoritmin
>> tarvitsema iteraattori.
> Juuri noinhan java.util.Collections:in metodit onkin toteutettu.
Alkaa iän myötä näemmä tuo näkö heiketä. Osoittaisitkos, missä tuossa
java.util.Collections-luokassa nuo luokkametodit käyttävät iteraattoreita?
Minä huomaan vain yhden,
static ArrayList java.util.Collections::list(Enumeration e);
jos sallit hieman C++-vaikutteisen syntaksin.
> Kysymys on vain siitä, millaisen rajapinnan kautta tuollaiset
> yleiskäyttöiset operaatiot pitäisi tarjota. Onko sinulla tarjota
> parempi vaihtoehto, miten java.util.Collections:in toiminnallisuus
> olisi pitänyt tarjota?
Pyydän sinua lukemaan tuo aiemman postini kommentin uudestaan tuosta pari
kappaletta ylempää. Joku minua viisaampi voisi tietty kertoa, onko STL:n
tapa todella Javan tapaa parempi.
> On aika vaikeaa pohtia "loppuun asti" kirjastoluokkaa, jonka on
> tarkoitus olla yleiskäyttöinen. Etenkin yksinkertaisille
Hop, polttamaan se GoF siitä :)
> tietorakenteille voi tehdä lukemattomia hyödyllisiä juttuja, joiden
> kaikkien pistäminen valmiiksi luokan metodeiksi paisuttaisi sitä
> älyttömästi.
Kaikkien luokkienko pitäisi siten olla yleiskäyttöisiä, eli sopia
tilanteeseen kuin tilanteeseen? Piste-luokka, jota voisi käyttää
pisteenä matemaattisessa lauseessa, piirto-ohjelmassa ja virkkeen lopussa?
Ei, tätä et varmasti tarkoita. Miksi ei sitten hoitaa suunnittelua
loppuun asti? Vain ne metodit luokkaan, mitä siellä tarvitaan? Uudet
metoditarpeethan hoidetaan joka tapauksessa refaktoroimalla ja
uudelleenkirjoittamalla "olan yli ohjelmoiden ikäänkuin XP-hengessä".
(Kiitos heitosta, Santtu!)
>> >> Tätä ongelmaa ei tietenkään esiinny sellaisissa oliokielissä, jotka
>> > eivät erottele funktioita ja metodeja (CLOS), tai ...
>>
>> Onkohan tuo nyt ihan noin? Sotketkos kenties metodit, geneeriset
>> funktiot ja funktiot keskenään?
> Tarkoitin, ettei erottele _syntaktisesti_ funktioiden ja metodien
> kutsumista, ...
Hyvä, nyt näyttää paremmalle.
Jonne
Lauri Alanko
Jonne Itkonen <j...@tarzan.it.jyu.fi> wrote:
> Lauri Alanko <l...@iki.fi> wrote:
> > Voi olla vähän hankalaa, jos kuitenkin tarvitaan apuoperaatioita
> > sellaiseen luokkaan, jonka lähdekoodia ei kerta kaikkiaan ole
> > saatavilla.
>
> Joo, tuossa tapauksessa kenties, mutta yllä kirjoitit mielestäni, että
> luokat pitäisi _suunnitella_ tuollaisiksi. Saatoinhan ymmärtää väärin...
Sanoin "käytännössä päädytään". Käytännön pakosta.
> >> Niinpä näyttävät pannahiset tekevän. Miksiköhän moinen? Miksi ei tehdä
> >> kuten C++:n iteraattoreilla, säilöillä ja algoritmeilla: Algoritmit
> >> kirjoitetaan käyttäen iteraattoreita, jolloin samaa algoritmia voi
> >> käyttää kaikkien niiden säilöjen kanssa, joille on olemassa algoritmin
> >> tarvitsema iteraattori.
>
> > Juuri noinhan java.util.Collections:in metodit onkin toteutettu.
>
> Alkaa iän myötä näemmä tuo näkö heiketä. Osoittaisitkos, missä tuossa
> java.util.Collections-luokassa nuo luokkametodit käyttävät iteraattoreita?
> Minä huomaan vain yhden,
> static ArrayList java.util.Collections::list(Enumeration e);
> jos sallit hieman C++-vaikutteisen syntaksin.
En oikein uskalla dumpata lähdekoodia, mutta katso itse, jos hyväksyt
J2SE:n sorsalisenssin:
http://wwws.sun.com/software/java2/download.html
No ehkä voin kertoa tämän verran: fill(List list, Object o) on
toteutettu niin, että otetaan list:in iteraattori, käydään sitä läpi,
ja iteraattorin kautta asetetaan listan kuhunkin kohtaan arvoksi o.
> > Kysymys on vain siitä, millaisen rajapinnan kautta tuollaiset
> > yleiskäyttöiset operaatiot pitäisi tarjota. Onko sinulla tarjota
> > parempi vaihtoehto, miten java.util.Collections:in toiminnallisuus
> > olisi pitänyt tarjota?
>
> Pyydän sinua lukemaan tuo aiemman postini kommentin uudestaan tuosta pari
> kappaletta ylempää. Joku minua viisaampi voisi tietty kertoa, onko STL:n
> tapa todella Javan tapaa parempi.
Kuten sanottu, tuo on juuri myös Javan tapa: kukin säiliöluokka
tarjoaa toteutuskohtaisen iteraattorin, ja geneeriset algoritmit
toteutetaan käyttäen näitä iteraattoreita (ja muita säiliöluokkien
toteuttamia ominaisuuksia).
Ero on vain siinä, että C++:ssa algoritmit ovat (esim.)
<algorithm>-otsakkeessa määriteltyjä funktioita, Javassa taas (esim.)
java.util.Collection:in staattisia metodeja. C++-funktioiden
tyypitystä lukuunottamatta ero on lähinnä kosmeettinen. Staattinen
metodi on käytännössä funktio. (Ja parametrinen polymorfismi
("templatet") tulee piakkoin Javaankin.)
> > tietorakenteille voi tehdä lukemattomia hyödyllisiä juttuja, joiden
> > kaikkien pistäminen valmiiksi luokan metodeiksi paisuttaisi sitä
> > älyttömästi.
>
> Kaikkien luokkienko pitäisi siten olla yleiskäyttöisiä, eli sopia
> tilanteeseen kuin tilanteeseen?
Ei kaikkien, mutta useiden kohdalla on se suotavaa. Etenkin jos kyse
on jostain ulkoisesta kirjastosta. Ja _etenkin_ kun kyse on yleisistä
tietorakenteista joita jok'ikinen kielellä ohjelmoiva käyttää.
> Uudet
> metoditarpeethan hoidetaan joka tapauksessa refaktoroimalla ja
> uudelleenkirjoittamalla "olan yli ohjelmoiden ikäänkuin XP-hengessä".
Sinulla tuntuu olevan jotenkin voimakas kuvitelma, että ohjelmoijalla
on aina pääsy kaiken sorsiin, ja että kun on, niin luokan
sorkkimisesta olisi aina enemmän hyötyä kuin haittaa.
Lauri Alanko
l...@iki.fi
Jonne Itkonen
> In article <ar3977$bkb$1...@mordred.cc.jyu.fi>,
> Jonne Itkonen <j...@tarzan.it.jyu.fi> wrote:
>> Lauri Alanko <l...@iki.fi> wrote:
> No ehkä voin kertoa tämän verran: fill(List list, Object o) on
==========
>> > Kysymys on vain siitä, millaisen rajapinnan kautta tuollaiset
Äh, nyt puhutaan eri asioista. Sinä puhut Javan fill()-luokkametodin
toteutuksesta, minä puhun metodien "otsakkeista". fill() on tehty
käyttämään List-rajapintaa, joka on _säilöluokan_ rajapinta.
C++:ssa algorithm-kilkkeet on tehty käyttämään _iteraattorien_
rajapintoja. Javan tapa riippuu _säilöluokan_rajapinnasta_, saa
siltä sitten millaisen iteraattorin tahansa. C++:n tapa ei riipu
säilöluokan, vaan _iteraattorin_rajapinnasta_.
Vertaapa tuota Javan fill:iä fill:iin :
template <class ForwardIterator, class T>
void fill(ForwardIterator first, ForwardIterator last, const T& value);
C++:n versio mahdollistaa algoritmin käytön, vaikkei kohde olisikaan
säilö. Javan versiossa täytyy kohteen olla säilö. Jos kohde Javan
versiossa ei ole säilö, joutuu se toteuttamaan väärän rajapinnan,
joka on vielä tuolla mainitsemallasi turvonneella tavalla väärä.
> Sinulla tuntuu olevan jotenkin voimakas kuvitelma, että ohjelmoijalla
> on aina pääsy kaiken sorsiin, ja että kun on, niin luokan
> sorkkimisesta olisi aina enemmän hyötyä kuin haittaa.
Siltä puolelta olen taas aistivinani, että kaikki ohjelmoijat
käyttävät vain muiden tekemiä kirjastoja, jotka ovat vielä
kaiken lisäksi huonoja, eikä mihinkään ole mahdollisuutta saati
lupaa kajota.
Todellisuus maannee jossain puolivälissä. En kuitenkaan pidä hyvänä
käytäntönä, että suunnittelu jätetään puolitiehen tai siirretään
tulevien tekijöiden vastuulle. Tästä on tarjolla pelottavana
esimerkkinä monet vanhat C-ohjelmat, joissa on haettu samanlaista
kaiken maailman koukkujen ja osoittimien osoittimien kanssa. Oliolla
operoitaessa on tarjolla vain hieman paremmin naamioitu tapa ampua
itseään jalkaan. Samat suot ne on rämmittävänä, käyttipä sitten
wanhoja osoitinkikkailuja tai nykyisiä oliokikkailuja. Ehkä
abstraktiotaso on hieman noussut.
Ja mitä luokkien sorkkimiseen tulee, no, sarkasmi on vaikea
taiteenlaji, enkä ole siinä todellakaan päässyt lähtökuoppia
pidemmälle.
Jonne
Jonne Itkonen
> Antoisa haastattelu APIn suunnittelusta:
> http://www.artima.com/intv/blochP.html
Joo, oli antoisa, suosittelen muillekin luettavaksi. Tosin kaikkia
hänen C++ ja Python kommentteja en allekirjoittaisi :) Täytyneepä
rohkaistua kysymään häneltä noista Collections:in luokkametodeista.
Jonne
Lauri Alanko
Jonne Itkonen <j...@tarzan.it.jyu.fi> wrote:
> C++:n versio mahdollistaa algoritmin käytön, vaikkei kohde olisikaan
> säilö. Javan versiossa täytyy kohteen olla säilö. Jos kohde Javan
> versiossa ei ole säilö, joutuu se toteuttamaan väärän rajapinnan,
> joka on vielä tuolla mainitsemallasi turvonneella tavalla väärä.
No niin, tajusinpa lopulta pointtisi. Mitä ilmeisesti yrität sanoa on,
että Javan rajapinnat ovat liian leveitä ja pakottavat luokan usein
väittämään toteuttavansa sellaisiakin operaatioita, joita se oikeasti
ei tue. Olen ihan samaa mieltä, tämä on huono juttu.
UnsupportedOperationExceptionia heitellään vähän siellä sun täällä
turhan vapaasti. Java ei kovin luontevasti tue tyyliä, jossa luokan
toiminnallisuus voidaan määritellä yksittäisten metodien tarkkuudella.
> Todellisuus maannee jossain puolivälissä. En kuitenkaan pidä hyvänä
> käytäntönä, että suunnittelu jätetään puolitiehen tai siirretään
> tulevien tekijöiden vastuulle.
Ei ole mahdollista suunnitella kirjastoa valmiiksi niin, että kaikki
kuviteltavissa olevat asiat, joita sillä voi tehdä, on toteutettu
etukäteen. Siispä, jos yleiskäyttöinen toiminnallisuudeltaan rajattu
mutta laajennettavissa oleva komponentti on sinusta huono idis, niin
sitten kaikkien täytynee kirjoittaa jokainen ohjelma joka kerta
tyhjästä.
Lauri Alanko
l...@iki.fi
Antti-Juhani Kaijanaho
In article <ar36pg$rjr$1...@oravannahka.helsinki.fi>, Lauri Alanko wrote:
> Tarkoitin, ettei erottele _syntaktisesti_ funktioiden ja metodien
> kutsumista, ja metodilla tässä tarkoitan yleisesti ad hoc-polymorfista
> operaatiota
Cardelli ja Wegner [1] jaottelivat 80-luvulla polymorfismin seuraavasti:
- universaalipolymorfismi (universal)
+ parametripolymorfismi (parametric)
+ inkluusiopolymorfismi (inclusion)
- satunnaispolymorfismi (ad hoc)
+ implisiittiset tyypinmuunnokset (coercion)
+ monimäärittely (overloading)
Metodien polymorfismi perustuu alityypitykseen, joten se kuuluu tässä
luokittelussa inkluusiopolymorfismin luokkaan.
Onko sinulla jokin erityinen syy laskea metodit ad hoc -luokkaan?
Seuraatko jotain toista luokittelua (mitä)?
[1] Luca Cardelli ja Peter Wegner, "On Understanding Types, Data
Abstraction and Polymorphism". ACM Computing Surveys, vol 17 no 4
(Dec 1985).
--
Antti-Juhani Kaijanaho, LuK (BSc) * http://www.iki.fi/gaia/ * ga...@iki.fi
[ Moderoijat tavoittaa osoitteesta saom-...@cc.jyu.fi ]
[ Ryhmän säännöt: http://www.iki.fi/gaia/saom/saannot.html ]
[ Ryhmän FAQ: http://www.iki.fi/gaia/faq/sao-faq.html ]