luokkien keksiminen

keksin yhden lisää kun kattelin penskojen cd:tä.
kuunnelma.

vai pitäisikö lähteä eri kantilta? jako ensin data ja audio...

Olio-ohjelmoinnin oppimateriaalissa tyypillisesti esitellään perintä tämän tyyppisellä kouluesimerkillä (pseudosyntaksilla ilmaistuna):

luokka Elukka
luokka Nisakas perii Elukka
luokka Lintu perii Elukka
luokka Koira perii Nisakas
jne.

Käsitteellisesti asia on hyvinkin kuta kuinkin näin. Samoin omassa esimerkissäsi, jossa mietit eri CD-levyjen aliluokkia.

luokka CD
luokka MusiikkiCD perii CD
luokka DataCD perii CD
jne.

Tämän tyyppisissä ratkaisuissa tulee hyvin nopeasti ongelmaksi se, että ohjelmaa täytyy muuttaa aina, kun käyttöön tarvitaan uusia CD-tyyppejä - koska ne on ilmaistu luokkina ohjelmakoodissa.

Kouluesimerkkien vastaisesti luokkia ei tule suunnitella datahierarkian mukaan. Luokat ja niiden mahdollinen periminen tulee suunnitella ohjelman teknisen toteutuksen helpottamiseksi, niin että sillä voi helposti esittää paljon erilaista dataa.

Ongelman havainnollistamiseksi voi vaikka miettiä, mitä tapahtuu, jos Elukka-kantaluokasta pitää alkaa periä lepakoita, nokkaeläimiä ja muita kummajaisia, joiden olemus edellyttää niiden esittämistä lento-ominaisuuksien tai munimisen kautta. Helvetti odottaa.

Samoin CD-hierarkiaa miettiessä tulee helposti mieleen, että pian erilaisia DataCD:n perillisiä alkaa ilmaantua mitä mielikuvituksellisimpiin tarkoituksiin. Tai jos MusiikkiCD:stä alkaa periä LastenMusiikkiCD:tä, RnBMusiikkiCD:tä, HeviCD:tä ja herratiesmitä, ollaan pian nesteessä. Ja sitten huomataankin, että kaikkea tätä voi tallentaa myös DVD-levyille. D'oh!

Kuitenkaan kaikkia mahdollisia attribuutteja (artisti, genre, media, sisältö, otsikko, levytysvuosi, ohjelmatyyppi, jne) ei kannata esittää yhdellä luokalla.

Mikä siis neuvoksi? Luokkien tuli helpottaa ohjelmointia, eikä vaikeuttaa sitä! Tavoitteenamme on tehdä niin geneeristä koodia kuin suinkin, tekemättä siitä silti monimutkaisempaa kuin on pakko.

Otetaan teknisempi lähestymistapa, ja käytetään luokkia helpottamaan erilaisten attribuuttikokonaisuuksien määrittelyä.

Määritellään luokka Attribuutti:
- jäsen nimi (merkkijono)
- jäsen arvo (merkkijono)

Määritellään luokka Tallenne:
- jäsen tunniste, kokonaisluku
- jäsen taulukko, jossa nolla tai useampia Attribuutteja

Näillä eväin data voidaan esittää geneerisesti, ja käyttöliittymä, jonka kautta dataa käsitellään, voidaan niinikään kirjoittaa geneeriseksi. Käyttäjän voi helposti antaa määritellä erilaisia attribuutteja ja antaa niille arvoja. Arvojen tallentaminen tiedostoon tai tietokantaan on triviaalia ja ennen kaikkea myös geneeristä. Koodiin voidaan tehdä valmiiksi erilaisia attribuuttikokonaisuuksia, kuten:

Musiikkitallenne
- media: CD, DVD tai käyttäjältä
- tyyppi: musiikki
- otsikko: (käyttäjältä)
- genre: (käyttäjältä)

Datatallenne
- media: CD, DVD tai käyttäjältä
- tyyppi: data
- otsikko: (käyttäjältä)
- ohjelmistotyyppi: toimisto, peli, ohjelmointi, apuohjelma tai käyttäjältä

jne.

Tämä onkin huomattavasti joustavampaa, ja mahdollistaa jopa sellaisen ohjelman tekemisen, jossa käyttäjä voi käyttöliittymässä määritellä uudentyyppisiä tallenteita!

Hommaa voi halutessan laajentaa esimerkiksi seuraavasti:

Määritellään enumeraatio AttribuuttiTyyppi:
- merkkijono
- kokonaisluku
- desimaaliluku
- totuusarvo (boolean)

Ja lisätään tämä Attribuutin jäseneksi kuvaamaan, no, attribuutin tyyppiä. Attribuutti voi olla oikeasti tallennettuna merkkijonona, mutta se voi tarvittaessa olla muunnettavissa joksikin muuksi tyypiksi, esimerkiksi kokonaisluvuksi laskutoimituksia varten. AttribuuttiTyyppi ei ole millään muotoa kriittinen luokka tässä.

Sen sijaan erityisesti hyödyksi voi olla määritellä luokka tai luokkia, jotka osaavat luoda templaatteja erilaisten tallennetyyppien pohjaksi. Nämä käsittelevät niinikään dataa yksinomaan Attribuutti-luokkina. Näitä voi olla valmiiksi ohjelmassa joku sopiva joukko, mutta käyttäjä voisi myös luoda niitä lisää. Voi olla, että templaatit kannattaa luoda ja lukea konfiguraatiotiedostosta. Tämäkin on triviaalia ja täysin geneeristä, kun data on ilmaistu yksinkertaisina Attribuutti-luokkina.

Huomaa, että perintää ei tarvitse käyttää koko roskassa ehkä lainkaan. Se, että perintä on teknisesti käytettävissä, ei tarkoita sitä, että sitä pitäisi aina käyttää.

Toivottavasti tästä on apua.