Pyyhkäise näyttääksesi valikon

Paras tapa ohittaa private-muuttujan näkyvyysmuuttuja

Kaikki Java-ohjelmoijat käyttävät rakenteita nimeltä getterit ja setterit.

Getterit ja setterit ovat metodeja, jotka noudattavat tiettyä kaavaa. Niitä käytetään ohittamaan private-näkyvyysmuuttuja ja mahdollistamaan kenttien käsittely toisesta luokasta.

Mitä getterit ja setterit tekevät

Yksinkertaisesti sanottuna setteri mahdollistaa arvon asettamisen tietylle kentälle, jota suojaa private-näkyvyysmuuttuja, kun taas getterin avulla voidaan hakea arvo kentästä, jota suojaa private-näkyvyysmuuttuja.

Getterin ja setterin syntaksi:

Main.java


              123456789
            
// getter
public fieldType getFieldName() {
    return field;
}

// setter
public void setFieldName(fieldType field) {
    this.field = field;
}

Kuten yllä olevasta koodista näkyy, käytämme metodeille nimeämiskäytäntöä getFieldName() ja setFieldName(). Jos meillä siis on kenttä private String name ja luomme getterin ja setterin nimillä getName() ja setName(), vastaavasti. On myös huomioitava, että getter palauttaa arvon, jonka tietotyyppi on sama kuin name-kentällä, kun taas setteri ottaa parametrin, jonka tietotyyppi on sama kuin name-kentällä.

Tämän avulla voimme käyttää kenttiä, joita suojaa private-näkyvyysmuuttuja. Katsotaanpa esimerkkiä siitä, miten päästään käsiksi private-kenttään Person-luokasta main-luokassa:

Main.java


              123456789101112131415161718192021
            
package com.example;

public class Main {
    public static void main(String[] args) {
        Person bob = new Person();
        bob.setName("Bob");
        System.out.println(bob.getName());
    }
}

class Person {
    private String name;

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }
}

Kuten huomaat, käytämme setteriä asettaaksemme arvon name-kentälle, ja sen jälkeen käytämme getter-metodia näyttääksesi name-kentän arvon näytöllä. Kiinnitä huomiota getter- ja setter-metodien syntaksiin sekä siihen, että name-kenttä Person-luokassa on suojattu private-näkyvyysmuuttujalla.

Konstruktori vs Getter/Setter

Kumpi on parempi käyttää, alustaminen konstruktorin avulla + toString()-metodin ylikirjoittaminen vai getterien ja setterien käyttö?

On ehdottomasti parempi käyttää gettereitä ja settereitä kenttiin, jotka on suojattu private-näkyvyysmuuttujalla. Tämä tarjoaa suurempaa joustavuutta koodissa ja parantaa sen luettavuutta. Kun näet getName()-metodin käytön koodissa, ymmärrät heti, että tämä metodi hakee kentän nimeltä name. Sama pätee, kun näet setName()-metodin käytön: ymmärrät heti, että asetat tietyn arvon kentälle kyseisen luokan olion yhteydessä. Jos muut ihmiset lukevat koodiasi, he ilahtuvat nähdessään getterit ja setterit.

On myös huomioitava, että jokainen kenttä tarvitsee oman getterin ja setterin. Jos luokalla on kaksi kenttää, jotka on suojattu private-näkyvyysmuuttujalla, luokalla tulisi olla yksi getter jokaista kenttää kohden, eli kaksi getteriä ja kaksi setteriä. Katsotaanpa esimerkkiä, jossa lisäämme age-kentän Person-luokkaan:

Main.java


              12345678910111213141516171819202122232425262728293031
            
package com.example;

public class Main {
    public static void main(String[] args) {
        Person bob = new Person();
        bob.setName("Bob");
        bob.setAge(27);
        System.out.println("Person's name: " + bob.getName() + ", Person's age: " + bob.getAge());
    }
}

class Person {
    private String name;
    private int age;

    public int getAge() {
        return age;
    }

    public void setAge(int age) {
        this.age = age;
    }

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }
}

Kuten huomaat, olemme luoneet jokaiselle Person-luokan kentälle yhden getterin ja yhden setterin. main-metodissa alustimme kentät setterin avulla ja näytimme niiden arvot näytöllä getterin avulla. Näiden metodien käyttö on erittäin kätevää, ja tulet käyttämään niitä usein tulevaisuudessa.