Hvorfor settere og gettere?

[dabear]

kan noen forklare meg hvorfor jeg skal bruke settere og gettere? Jeg kan skjønne det om du skal ha noe mer logikk (sjekke at du ikke tar ut mer enn kontogrense feks), men oftest ser jeg slik kode;

 

 private type fooVar;

public type getFooVar() {
 return fooVar;
}
public void setFooVar(type fooVar) {
 this.fooVar = fooVar;
}

Hvorfor ikke bare

 public type fooVar;

og så sette eller hente ut objektet.fooVar direkte?

Endret 5. mars 2008 av dabear

[hishadow]

Problemet er at du "låser" fast variabelen når den tas i bruk av annen kode og det blir vanskelig å gjøre endringer, som f.eks. at du senere finner ut at du vil gjøre en sjekk på verdien som tilegnes variabelen. Da må denne sjekken gjøres manuelt overalt hvor du brukte variabelen.

 

For din egen del må du selv se hvor det er nyttig å bruke settere/gettere kontra variabel.

Endret 5. mars 2008 av hishadow

[HV]

Tror det finnes design pattern på at man skal kapsulere informasjon. Forøvrig tror jeg også det er en veldig java spesifikk ting kontra andre språk, bean standard.

 

 

Hva hvis type hadde vært String og du hadde brukt "objektet.fooVar" 100 plasser i koden din og plutselg fant ut at du ville vise den teksten i kun store bokstaver overalt? Hadde kanskje vært enklere å gjøre dette da, istedefor å bytte ut alle 100? Vet ikke om dette er beste eksemplet men men..

public String getFooVar() {
 return fooVar.toUpperCase...;
}

[pgdx]

Tja, det er jo mange steder man kunne brukt feltvariabler for å sette og hente informasjon, men i de aller fleste tilfeller ønsker man kontroll over hva en feltvariabel kan settes til (e.g. nullpekere, tomme strenger, 0, <0, etc.) og ofte vil man gjøre noe når man bruker getter-metoder. Man kan for eksempel ønske å sjekke om en variabel er instansiert når en getter kjøres, og hvis den ikke er det, så ønsker man å instansiere den før den returneres.

 

I alle andre tilfeller, hvor man kun gir tilgang til variablene uten å gjøre noe annet, fungerer getters og setters ved 1) innkapsling og 2) følge standarder/konvensjoner.

 

Når man skriver et interface, definerer man hvilke metoder folk skal ha tilgang til. La oss anta at det hadde vært mulig å definere hvilke feltvariabler folk skulle hatt tilgang til også. Da hadde det vært umulig å skrive en klasse som gjorde noe ekstra hver gang man aksesserte en viss variabel. Dårlig forklaring, men når du har skrevet en del OOP forstår du det fort.

[___]

Hvorfor ha tenningslås i en bil, når man bare kan sette etpar ledninger mot hverandre?

 

Ideen med gettere og settere, er at i den objektorienterte verden, skal ikke noen trenge å vite hvordan en klasse er implementert. En annen ting er selvfølgelig at implementasjonen kan forandres, selv om metodesignaturene forblir faste. Benytter du gettere og settere, skal du da i utgangspunktet ikke trenge å være så bekymret.

 

Hvis du skriver kode som benytter seg av en klasse som en kollega har skrevet, og som du tilfeldigvis har kildekoden til, så er det lett å bli fristet til å ta snarveier ved å aksessere interne variabler i klassen.

 

Hvis din kollega en dag skriver om klassen, og for eksempel omdøper, eller i verste fall fjerner en eller annen variabel du har vært så smart å benytte direkte, ja da fungerer ikke koden din lenger. I beste fall fungerer koden din annerledes, fordi variabelen kanskje brukes til noe annet, eller kanskje ikke brukes i det hele tatt.

 

Eksempelet med tenningslåsen viser at du ikke nødvendigvis trenger å vite hva som ligger mellom tenningslåsen og motoren, for å starte bilen. Og selv om det faktisk går an å tjuvkoble en bil, så er det ikke gitt at framgangsmåten forblir den samme for all fremtid.

 

Werner