Miksi, oi miksi, Java ei tue const-määrettä??? Nyt pitää luoda aina kaksi helvetin luokkaa, joista toinen on ns. immutable, jotta saa saman homman aikaseksi. (eli metodin public Vector haeVektori(); palauttaman vektorin arvoja ei voi muutaa: public ImmutableVector haeVektori(); kun saman asian vois vain hoitaa yhdellä sanalla public const Vector haeVektori(); ). Rasittavaa!
Perziistä!
4
395
Vastaukset
- loxomor
Miksi pitää tehdä kaksi luokkaa? Kerro hyvä syy!
Epäilen, että tässä on nyt kyseessä huono ohjelman suunnittelu eikä niinkään Javan puute!- muuttamattomuuden sääntö
>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ö? - loxomor
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ö?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. - fidel1
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ö?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.
Ketjusta on poistettu 0 sääntöjenvastaista viestiä.
Luetuimmat keskustelut
Suureksi onneksesi on myönnettävä
Että olen nyt sitten mennyt rakastumaan sinuun. Ei tässä mitään, olen kärsivällinen ❤️932059Perusmuotoiset TV-lähetykset loppu
Nyt sanoo useiden HD-muotoistenkin kanavien kohdalla äly-TV, ettei kanava ole käytössä, haluatko poistaa sen? Kanavia1671520YLE Äänekosken kaupunginjohtaja saa ankaraa arvostelua
Kaupungin johtaja saa ankaraa kritiikkiä äkkiväärästä henkilöstöjohtamisestaan. Uusin häirintäilmoitus päivätty 15 kesä741289Euroopan lämpöennätys, 48,8, astetta, on mitattu Italian Sisiliassa
Joko hitaampikin ymmärtää. Se on aivan liikaa. Ilmastonmuutos on totta Euroopassakin.2361170- 731160
Hyvin. Ikävää nainen,
Että vainoat ja stalkkaat miestäni.onko tarkoituksesi ehkä saada meidät eroamaan?no,siinä et tule onnistumaan871074Martina lähdössä Ibizalle
Eikä Eskokaan tiennyt matkasta. Nyt ollaan jännän äärellä.1501018Asiakas iski kaupassa varastelua tehneen kanveesiin.
https://www.iltalehti.fi/kotimaa/a/33a85463-e4d5-45ed-8014-db51fe8079ec Oikein. Näin sitä pitää. Kyllä kaupoissa valtava243962Katsoin mies itseäni rehellisesti peiliin
Ja pakko on myöntää, että rupsahtanut olen 😆. Niin se ikä saavuttaa meidät kaikki.51916Uskomaton tekninen vaaliliitto poimii rusinoita pullasta
Korni näytösesitelmä menossa kaupunginvaltuustossa. Juhlia ei ole kokouksista tiedossa muilla, kuin monipuolue paikalli88891