Java Language
Getters en Setters

Invoering

Getters en Setters toevoegen

Inkapseling is een basisconcept in OOP. Het gaat om het inpakken van gegevens en code als een enkele eenheid. In dit geval is het een goede gewoonte om de variabelen als private te verklaren en ze vervolgens via Getters en Setters te openen om ze te bekijken en / of te wijzigen.

public class Sample {
  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;
  }
}

Deze privévariabelen zijn niet rechtstreeks toegankelijk van buiten de klas. Daarom zijn ze beschermd tegen ongeautoriseerde toegang. Maar als u ze wilt bekijken of wijzigen, kunt u Getters en Setters gebruiken.

getXxx() methode getXxx() retourneert de huidige waarde van de variabele xxx , terwijl u de waarde van de variabele xxx kunt instellen met setXxx() .

De naamgeving van de methoden (in voorbeeld variabele genoemd variableName ):

• Alle niet- boolean variabelen

   getVariableName()   //Getter, The variable name should start with uppercase
   setVariableName(..) //Setter, The variable name should start with uppercase
  

• boolean variabelen

    isVariableName()     //Getter, The variable name should start with uppercase
    setVariableName(...) //Setter, The variable name should start with uppercase
  

Public Getters en Setters maken deel uit van de eigenschapdefinitie van een Java-bonen.

Een setter of getter gebruiken om een beperking te implementeren

Met Setters en Getters kan een object privévariabelen bevatten die met beperkingen kunnen worden geopend en gewijzigd. Bijvoorbeeld,

public class Person {

    private String name;

    public String getName() {
        return name;
    }

    public void setName(String name) {
        if(name!=null && name.length()>2)
           this.name = name;
    }
}

In deze klasse Person is er één variabele: name . Deze variabele kan worden geopend met de methode getName() en worden gewijzigd met de methode setName(String) . Voor het instellen van een naam moet de nieuwe naam echter langer zijn dan 2 tekens en mag deze niet null zijn. Door een setter-methode te gebruiken in plaats van de variabele name openbaar te maken, kunnen anderen de waarde van de name met bepaalde beperkingen. Hetzelfde kan worden toegepast op de getter-methode:

public String getName(){
   if(name.length()>16)
      return "Name is too large!";
   else
      return name;
}

In de gewijzigde methode getName() hierboven wordt de name alleen geretourneerd als de lengte ervan kleiner is dan of gelijk aan 16. Anders wordt "Name is too large" geretourneerd. Hierdoor kan de programmeur variabelen maken die bereikbaar en aanpasbaar zijn zoals ze willen, waardoor wordt voorkomen dat clientklassen de variabelen ongewenst bewerken.

Waarom getters en setters gebruiken?

Overweeg een basisklasse met een object met getters en setters in Java:

public class CountHolder {
  private int count = 0;

  public int getCount() { return count; }
  public void setCount(int c) { count = c; }
}

We hebben geen toegang tot de count omdat deze privé is. Maar we hebben toegang tot de getCount() en setCount(int) omdat deze openbaar zijn. Voor sommigen kan dit de vraag opwerpen; waarom de tussenpersoon introduceren? Waarom laten ze ze niet gewoon openbaar worden?

public class CountHolder {
  public int count = 0;
}

Voor alle doeleinden zijn deze twee qua functionaliteit exact hetzelfde. Het verschil tussen hen is de uitbreidbaarheid. Overweeg wat elke klas zegt:

• Ten eerste : "Ik heb een methode die je een int waarde geeft en een methode die die waarde op een andere int zal zetten".
• Ten tweede : "Ik heb een int die u kunt instellen en krijgen zoals u wilt."

Deze klinken misschien hetzelfde, maar de eerste is eigenlijk veel meer bewaakt in zijn aard; het laat je alleen interageren met zijn interne aard zoals het dicteert. Dit laat de bal in zijn baan; het bepaalt hoe de interne interacties plaatsvinden. De tweede heeft zijn interne implementatie extern blootgelegd en is nu niet alleen gevoelig voor externe gebruikers, maar, in het geval van een API, toegewijd aan het handhaven van die implementatie (of anders een niet-achterwaarts compatibele API vrij te geven).

Laten we overwegen of we de toegang tot het wijzigen en toegang tot de telling willen synchroniseren. In de eerste is dit eenvoudig:

public class CountHolder {
  private int count = 0;

  public synchronized int getCount() { return count; }
  public synchronized void setCount(int c) { count = c; }
}

maar in het tweede voorbeeld is dit nu bijna onmogelijk zonder door te gaan en elke plaats te wijzigen waar naar de count wordt verwezen. Erger nog, als dit een item is dat u in een bibliotheek aanbiedt om door anderen te worden geconsumeerd, hebt u geen manier om die wijziging uit te voeren en bent u gedwongen de hierboven genoemde moeilijke keuze te maken.

Dus het roept de vraag op; zijn openbare variabelen ooit een goede zaak (of in ieder geval niet slecht)?

Ik weet het niet zeker. Aan de ene kant zie je voorbeelden van openbare variabelen die de tand des tijds hebben doorstaan (IE: de variabele out waarnaar wordt verwezen in System.out ). Anderzijds biedt het verschaffen van een publieke variabele geen voordeel buiten extreem minimale overhead en mogelijke vermindering van de woordigheid. Mijn richtlijn hier zou zijn dat, als u van plan bent om een variabele openbaar te maken, u deze met extreme vooroordelen moet beoordelen:

1. De variabele mag geen denkbare reden hebben om de implementatie ooit te wijzigen. Dit is iets dat heel gemakkelijk te verknallen is (en, zelfs als je het goed hebt, kunnen vereisten veranderen), dat is waarom getters / setters de gebruikelijke aanpak zijn. Als je een openbare variabele hebt, moet dit echt goed worden doordacht, vooral als het wordt vrijgegeven in een bibliotheek / framework / API.
2. De variabele moet vaak genoeg worden vermeld dat de minimale voordelen van het verminderen van verbosity dit rechtvaardigen. Ik denk zelfs niet dat hier rekening moet worden gehouden met de overhead voor het gebruik van een methode versus direct verwijzen. Het is veel te verwaarloosbaar voor wat ik conservatief zou schatten als 99,9% van de applicaties.

Er is waarschijnlijk meer dan ik niet heb overwogen vanuit mijn hoofd. Gebruik altijd getters / setters als je ooit twijfelt.