Perziistä!

>Miksi pitää tehdä kaksi luokkaa? Kerro hyvä syy!

No enkö juuri kertonut? Jotta olion tilaa ei voi muuttaa suorituksen aikana! Otetaampas esimerkki.

Olkoon vaikka luokka "Henkilo" joka sisältää vaikka seuraavat tiedot:

public class Henkilö
{
protected int ikä;
protected String nimi;

public void haeIkä() { return ikä; }
public String haeNimi() { return nimi; }

public void asetaIkä(int ikä) { this.ikä = ikä; }
public void asetaNimi(String nimi) { this.nimi = nimi; }
}

Tässä tapauksessahan kyseessä on täysin muunneltavissa oleva luokka, koska se sisältää myös setterit. Nyt jos vaikka luetaan tietoja XML-tiedostosta vektoriin Vector, ja tiedetään että nämä tiedot pysyvät vakiona koko ohjelman suorituksen ajan, eli niitä ei saa muuttaa, niin kuitenkaan mikään ei estä ohjelmoijaa (vaikka vahingossa) muuttamasta Henkilö-olioiden arvoja.

Sen sijaan jos käytössä olisi "immutable", "const", "readonly", tai muu avainsana, homma hoituisi sillä helposti - vähän niinkuin C :ssa.

public immutable Vector haeHenkilöt(); vs.
public: const& std::vector HaeHenkilot();

Nyt jos käytetään setteriä, tai mitä tahansa muuta olion tilaa muuttavaa metodia tämän readonly-olion kautta, niin lentää poikkeus.

Nyt ainoaksi ratkaisuksi jää tehdä kaksi luokkaa, joista pohjaluokka on immutable ja aliluokka sisältää setterit, eli esim seuraavanlaisesti:

public class Henkilö
{
protected int ikä;
protected String nimi;

public void haeIkä() { return ikä; }
public String haeNimi() { return nimi; }
}

class MuutettavaHenkilö extends Henkilö
{
public void asetaIkä(int ikä) { this.ikä = ikä; }
public void asetaNimi(String nimi) { this.nimi = nimi; }
}

Tässä vektoriin luodaan siis MuutettavaHenkilö-olioita, ja kaikki metodit jotka haluaa palauttaa "readonly"-tyyppisen version Henkilöstä palauttaa olion Henkilö-tyyppisenä.

Työlästä ja turhauttavaa, eikö?

muuttamattomuuden sääntö kirjoitti:

>Miksi pitää tehdä kaksi luokkaa? Kerro hyvä syy!

No enkö juuri kertonut? Jotta olion tilaa ei voi muuttaa suorituksen aikana! Otetaampas esimerkki.

Olkoon vaikka luokka "Henkilo" joka sisältää vaikka seuraavat tiedot:

public class Henkilö
{
protected int ikä;
protected String nimi;

public void haeIkä() { return ikä; }
public String haeNimi() { return nimi; }

public void asetaIkä(int ikä) { this.ikä = ikä; }
public void asetaNimi(String nimi) { this.nimi = nimi; }
}

Tässä tapauksessahan kyseessä on täysin muunneltavissa oleva luokka, koska se sisältää myös setterit. Nyt jos vaikka luetaan tietoja XML-tiedostosta vektoriin Vector, ja tiedetään että nämä tiedot pysyvät vakiona koko ohjelman suorituksen ajan, eli niitä ei saa muuttaa, niin kuitenkaan mikään ei estä ohjelmoijaa (vaikka vahingossa) muuttamasta Henkilö-olioiden arvoja.

Sen sijaan jos käytössä olisi "immutable", "const", "readonly", tai muu avainsana, homma hoituisi sillä helposti - vähän niinkuin C :ssa.

public immutable Vector haeHenkilöt(); vs.
public: const& std::vector HaeHenkilot();

Nyt jos käytetään setteriä, tai mitä tahansa muuta olion tilaa muuttavaa metodia tämän readonly-olion kautta, niin lentää poikkeus.

Nyt ainoaksi ratkaisuksi jää tehdä kaksi luokkaa, joista pohjaluokka on immutable ja aliluokka sisältää setterit, eli esim seuraavanlaisesti:

public class Henkilö
{
protected int ikä;
protected String nimi;

public void haeIkä() { return ikä; }
public String haeNimi() { return nimi; }
}

class MuutettavaHenkilö extends Henkilö
{
public void asetaIkä(int ikä) { this.ikä = ikä; }
public void asetaNimi(String nimi) { this.nimi = nimi; }
}

Tässä vektoriin luodaan siis MuutettavaHenkilö-olioita, ja kaikki metodit jotka haluaa palauttaa "readonly"-tyyppisen version Henkilöstä palauttaa olion Henkilö-tyyppisenä.

Työlästä ja turhauttavaa, eikö?

Lue lisää

Noh noh. Miten olis tällänen skenaario:

Sulla on luokka Henkilötietokanta.

Tämän luokan oliot osaa lukea XML tiedostosta henkilöt vektoriin.

Henkilötietokanta-luokassa on metodi, joka palauttaa vektorin, johon henkilöt on luettu.

Mutta paluuarvo on kopio. Toisin sanoen, Henkilötietokanta-luokan oliot pitävät itsellään alkuperäisen listan ja palauttavat siitä vain kopioita. Näin ei mikään muu olio pääse muuttamaan alkuperäisiä tietoja.

muuttamattomuuden sääntö kirjoitti:

>Miksi pitää tehdä kaksi luokkaa? Kerro hyvä syy!

No enkö juuri kertonut? Jotta olion tilaa ei voi muuttaa suorituksen aikana! Otetaampas esimerkki.

Olkoon vaikka luokka "Henkilo" joka sisältää vaikka seuraavat tiedot:

public class Henkilö
{
protected int ikä;
protected String nimi;

public void haeIkä() { return ikä; }
public String haeNimi() { return nimi; }

public void asetaIkä(int ikä) { this.ikä = ikä; }
public void asetaNimi(String nimi) { this.nimi = nimi; }
}

Tässä tapauksessahan kyseessä on täysin muunneltavissa oleva luokka, koska se sisältää myös setterit. Nyt jos vaikka luetaan tietoja XML-tiedostosta vektoriin Vector, ja tiedetään että nämä tiedot pysyvät vakiona koko ohjelman suorituksen ajan, eli niitä ei saa muuttaa, niin kuitenkaan mikään ei estä ohjelmoijaa (vaikka vahingossa) muuttamasta Henkilö-olioiden arvoja.

Sen sijaan jos käytössä olisi "immutable", "const", "readonly", tai muu avainsana, homma hoituisi sillä helposti - vähän niinkuin C :ssa.

public immutable Vector haeHenkilöt(); vs.
public: const& std::vector HaeHenkilot();

Nyt jos käytetään setteriä, tai mitä tahansa muuta olion tilaa muuttavaa metodia tämän readonly-olion kautta, niin lentää poikkeus.

Nyt ainoaksi ratkaisuksi jää tehdä kaksi luokkaa, joista pohjaluokka on immutable ja aliluokka sisältää setterit, eli esim seuraavanlaisesti:

public class Henkilö
{
protected int ikä;
protected String nimi;

public void haeIkä() { return ikä; }
public String haeNimi() { return nimi; }
}

class MuutettavaHenkilö extends Henkilö
{
public void asetaIkä(int ikä) { this.ikä = ikä; }
public void asetaNimi(String nimi) { this.nimi = nimi; }
}

Tässä vektoriin luodaan siis MuutettavaHenkilö-olioita, ja kaikki metodit jotka haluaa palauttaa "readonly"-tyyppisen version Henkilöstä palauttaa olion Henkilö-tyyppisenä.

Työlästä ja turhauttavaa, eikö?

Lue lisää

Siis haluatko, että Vectorista löytyviä Henkilo-instansseja ei saa muuttaa, vai että Vectorin sisältöä ei saa muuttaa?

public: const& std::vector HaeHenkilot();

En tunne C :aa kovin hyvin, mutta eikös tuossa nyt ole const vector, jonka sisältöä ei voi muuttaa (eli poistaa tai lisätä Henkilo-instansseja), mutta vectorin sisältämiä Henkilo-instanssien ominaisuuksia voi muuttaa mielin määrin?

Jos asia on näin, niin suosittelen tutustumaan java.util.Collections-luokan unmodifiableCollection()-metodiin (ja muihin unmodifiable*()-metodeihin)

----

Jos taas C :n const-määre tosissaan lukitsee myös vectorin sisältämät instanssit, niin sitten se onkin makuasia. Musta javan tapa tehdä hoitaa homma rajapinnoilla on selkeämpi, tällöin ohjelmoija ei edes vahingossa voi yrittää muuttaa olion tilaa. Se nyt kuitenkin on parempi vaihtoehto, kuin ylimääräinen ja tässä tapauksessa turha exception-käsittely.

Siis: tee rajapinta Henkilo:

public interface Henkilo {
public int haeIka();
public String haeNimi();
}

ja määritä Vectorisi sisältämään noita:

Vector henkilot = new Vector();

Ja sitten hoidat XML-tiedoston käsittelyn paikassa, joka ei näy muualle ohjelmakoodiin ja tunget Vectoriin Henkilo-rajapinnan toteuttavia luokkia, joilla voi täysin vapaasti olla vaikka minkälaisia settereitä, vektorin kautta käytettynä kun ohjelmoija ei niitä näe.