Hoe kan ik de set- en get-methoden gebruiken en waarom zou ik ze gebruiken? Zijn ze echt behulpzaam? En kun je me ook voorbeelden geven van set- en get-methoden?
Antwoord 1, autoriteit 100%
Set- en Get-methoden zijn een patroon van gegevensinkapseling. In plaats van rechtstreeks toegang te krijgen tot klassenlidvariabelen, definieert u getmethoden om toegang te krijgen tot deze variabelen, en setmethoden om ze te wijzigen. Door ze op deze manier in te kapselen, heb je controle over de openbare interface, mocht je de interne werking van de klas in de toekomst moeten veranderen.
Bijvoorbeeld voor een lidvariabele:
Integer x;
Je hebt misschien methoden:
Integer getX(){ return x; }
void setX(Integer x){ this.x = x; }
chiccodoronoemde ook een belangrijk punt. Als u alleen leestoegang tot het veld wilt toestaan voor buitenlandse klassen, kunt u dat doen door alleen een openbare get-methode op te geven en de setprivé te houden of geen sethelemaal.
Antwoord 2, autoriteit 39%
Ik wil aan andere antwoorden toevoegen dat setters kunnen worden gebruikt om te voorkomen dat het object in een ongeldige staat wordt geplaatst.
Laten we bijvoorbeeld aannemen dat ik een TaxId moet instellen, gemodelleerd als een String. De eerste versie van de setter kan als volgt zijn:
private String taxId;
public void setTaxId(String taxId) {
this.taxId = taxId;
}
We kunnen echter beter voorkomen dat het object wordt ingesteld met een ongeldige taxId, zodat we een controle kunnen invoeren:
private String taxId;
public void setTaxId(String taxId) throws IllegalArgumentException {
if (isTaxIdValid(taxId)) {
throw new IllegalArgumentException("Tax Id '" + taxId + "' is invalid");
}
this.taxId = taxId;
}
De volgende stap, om de modulariteit van het programma te verbeteren, is om de taxider zelf als een object te maken, in staat om zichzelf te controleren.
private final TaxId taxId = new TaxId()
public void setTaxId(String taxIdString) throws IllegalArgumentException {
taxId.set(taxIdString); //will throw exception if not valid
}
Evenzo voor de Getter, wat als we nog geen waarde hebben? Misschien willen we een ander pad hebben, we zouden kunnen zeggen:
public String getTaxId() throws IllegalStateException {
return taxId.get(); //will throw exception if not set
}
Antwoord 3, Autoriteit 14%
Ik denk dat je zoiets wilt:
public class Person {
private int age;
//public method to get the age variable
public int getAge(){
return this.age
}
//public method to set the age variable
public void setAge(int age){
this.age = age;
}
}
U roept eenvoudig een dergelijke methode op in een object-exemplaar. Dergelijke methoden zijn nuttig, vooral als het instellen van iets zou bijwerkingen hebben. B.v. Als u wilt reageren op bepaalde gebeurtenissen zoals:
public void setAge(int age){
this.age = age;
double averageCigarettesPerYear = this.smokedCigarettes * 1.0 / age;
if(averageCigarettesPerYear >= 7300.0) {
this.eventBus.fire(new PersonSmokesTooMuchEvent(this));
}
}
Natuurlijk kan dit gevaarlijk zijn als iemand vergeet setAge(int)te bellen waar hij moet en agerechtstreeks instelt met this.age.
Antwoord 4, autoriteit 11%
Het hebben van accessor-methoden heeft de voorkeur boven directe toegang tot velden, omdat het bepaalt hoe velden worden benaderd (kan gegevenscontrole opleggen, enz.) en past bij interfaces (interfaces kunnen niet vereisen dat velden aanwezig zijn, alleen methoden).
Antwoord 5, autoriteit 9%
Setters en getters worden gebruikt ter vervanging van direct toegankelijke lidvariabelen van externe klassen. als u een setter en getter gebruikt om toegang te krijgen tot een eigenschap, kunt u initialisatie, foutcontrole, complexe transformaties, enz. opnemen. Enkele voorbeelden:
private String x;
public void setX(String newX) {
if (newX == null) {
x = "";
} else {
x = newX;
}
}
public String getX() {
if (x == null) {
return "";
} else {
return x;
}
}
Antwoord 6, autoriteit 7%
Enkele voordelen van het gebruik van getters en setters (bekend als encapsulationof data-hiding):
(oorspronkelijk hierbeantwoord)
1. De velden van een klasse kunnen alleen-lezen worden gemaakt (door alleen de getter op te geven) of alleen-schrijven (door alleen de setter op te geven). Dit geeft de klas volledige controle over wie de velden mag openen/wijzigen.
Voorbeeld:
class EncapsulationExample {
private int readOnly = -1; // this value can only be read, not altered
private int writeOnly = 0; // this value can only be changed, not viewed
public int getReadOnly() {
return readOnly;
}
public int setWriteOnly(int w) {
writeOnly = w;
}
}
2. De gebruikers van een klasse hoeven niet te weten hoe de klasse de gegevens daadwerkelijk opslaat. Dit betekent dat gegevens gescheiden zijn en onafhankelijk van de gebruikers bestaan, waardoor de code gemakkelijker kan worden gewijzigd en onderhouden. Hierdoor kunnen de beheerders regelmatig wijzigingen aanbrengen, zoals bugfixes, ontwerp- en prestatieverbeteringen, zonder dat dit gevolgen heeft voor gebruikers.
Bovendien zijn ingekapselde bronnen uniform toegankelijk voor elke gebruiker en vertonen ze identiek gedrag, onafhankelijk van de gebruiker, aangezien dit gedrag intern in de klas wordt gedefinieerd.
Voorbeeld (een waarde ophalen):
class EncapsulationExample {
private int value;
public int getValue() {
return value; // return the value
}
}
Wat als ik in plaats daarvan twee keer de waarde zou willen retourneren? Ik kan gewoon mijn getter wijzigen en alle code die mijn voorbeeld gebruikt, hoeft niet te veranderen en krijgt twee keer de waarde:
class EncapsulationExample {
private int value;
public int getValue() {
return value*2; // return twice the value
}
}
3. Maakt de code schoner, leesbaarder en gemakkelijker te begrijpen.
Hier is een voorbeeld:
Geen inkapseling:
class Box {
int widthS; // width of the side
int widthT; // width of the top
// other stuff
}
// ...
Box b = new Box();
int w1 = b.widthS; // Hm... what is widthS again?
int w2 = b.widthT; // Don't mistake the names. I should make sure I use the proper variable here!
Met inkapseling:
class Box {
private int widthS; // width of the side
private int widthT; // width of the top
public int getSideWidth() {
return widthS;
}
public int getTopWIdth() {
return widthT;
}
// other stuff
}
// ...
Box b = new Box();
int w1 = b.getSideWidth(); // Ok, this one gives me the width of the side
int w2 = b.getTopWidth(); // and this one gives me the width of the top. No confusion, whew!
Kijk hoeveel meer controle je hebt over welke informatie je krijgt en hoeveel duidelijker dit is in het tweede voorbeeld. Let wel, dit voorbeeld is triviaal en in het echte leven zijn de klassen waar je mee te maken hebt veel bronnen die door veel verschillende componenten worden gebruikt. Het inkapselen van de bronnen maakt het dus duidelijker welke we gebruiken en op welke manier (verkrijgen of instellen).
Hier is good SO threadover dit onderwerp.
Hier is good readover gegevensinkapseling.
Antwoord 7, autoriteit 4%
De bovenstaande antwoorden vatten de rol van getters en setters beter samen dan ik zou kunnen, maar ik wilde er wel aan toevoegen dat je code idealiter zo gestructureerd zou moeten zijn dat het gebruik van pure getters en setters, dat wil zeggen die zonder complexe constructies, validatie en enzovoort, terwijl ze de inkapseling doorbreken. Dit betekent niet dat je ze nooit kunt gebruiken (stivlo’s antwoord toont een voorbeeld van een goed gebruik van getters en setters), probeer gewoon te minimaliseren hoe vaak je ze gebruikt.
Het probleem is dat getters en setters kunnen fungeren als een tijdelijke oplossing voor directe toegang tot privégegevens. Privégegevens worden privé genoemd omdat ze niet bedoeld zijn om met andere objecten te worden gedeeld; het is bedoeld als een weergave van de staat van het object. Andere objecten toegang geven tot de privévelden van een object gaat voorbij aan het hele doel om het in de eerste plaats privé te maken. Bovendien introduceer je koppeling voor elke getter of setter die je schrijft. Denk bijvoorbeeld aan dit:
private String foo;
public void setFoo(String bar) {
this.foo = bar;
}
Wat gebeurt er als je ergens verderop besluit dat je foo niet meer nodig hebt, of dat je er een geheel getal van wilt maken? Elk object dat de setFoo-methode gebruikt, moet nu samen met foo worden gewijzigd.
Antwoord 8, autoriteit 4%
alleen maar omdat de OOP-regel: gegevens verbergen en inkapselen. Het is een zeer slechte gewoonte om een object openbaar te maken en in de meeste situaties direct te wijzigen. Er zijn ook veel andere redenen, maar de root is Encapsulation in OOP. en “koop een boek of ga lezen over objectgeoriënteerd programmeren”, je zult alles hierover begrijpen nadat je een boek over OOP hebt gelezen.
Antwoord 9, autoriteit 2%
De voordelen van get() set() methoden zijn als volgt ..
- U kunt uw object gemakkelijk serialiseren.
- Je kunt een persistent object maken van de bevattende klasse.
- U kunt de eigenschappen eenvoudig naar JSON converteren.
- In de DAO-laag (Frameworks zoals Hibernate) kun je het object direct in DB opslaan.
- Eenvoudig begrip van objectgeoriënteerd concept.
- Behoeften in alle ontwerppatronen behalve mogelijk in eenkleurig patroon.
- Beveiliging voor eigendommen die directe toegang beschermen.
- Polymorfisme, inkapseling kan gemakkelijk worden begrepen en geïmplementeerd door dit type klasse.
Voorbeeld:
private String personName;
private int personId;
public void setPersonName(String name) throws Exception{
if(!(name.equals("")||name=="")){
this.personName = name;
}
}
public String getPersonName(){
return this.personName;
}
public void setPersonId(int id) throws Exception{
this.personId = id;
}
public int getPersonId(){
return this.personId;
}
Antwoord 10, autoriteit 2%
Bovenstaande antwoorden gaan er allemaal van uit dat het object in kwestie een object met gedrag is.
Een geavanceerde strategie in OOP is het scheiden van gegevensobjecten (die wel zippen, alleen velden hebben) en gedragsobjecten.
Bij data-objecten is het prima om getters weg te laten en in plaats daarvan openbare velden te gebruiken. Ze hebben meestal geen setters, omdat ze meestal onveranderlijk zijn – hun velden worden ingesteld via de constructors en nooit meer.
Bekijk Bob Martin’s Clean Codeof Pryce and Freeman’s Groeiende OO-software…voor details.
Antwoord 11, autoriteit 2%
public class Person{
private int age;
public int getAge(){
return age;
}
public void setAge(int age){
this.age = age;
}
}
Ik denk dat dit je wilt ..
En dit heeft ook pojo
genoemd
Antwoord 12
Dit is de code voor ingestelde methode
public void setAge(int age){
this.age = age;
}
Antwoord 13
Het ziet eruit alsof je iets lijkt te doen dat lijkt op C # als je wilt dat setnage methode maken setAge(int age){
this.age = age;}
Antwoord 14
Ik zie geen eenvoudig antwoord op de tweede vraag (waarom) hier. Dus hier gaat.
Laten we zeggen dat je een openbaar veld hebt dat heel vaak in je code wordt gebruikt. Wanneer u besluit, moet u iets extra’s doen voordat u dit veld geeft of instelt, heeft u een probleem. U moet een speciale getter en setter maken voor dit veld en uw volledige code wijzigen van het gebruik van het veld rechtstreeks naar het gebruik van de Getter en Setters.
Stel je nu voor dat je een bibliotheek ontwikkelt die op grote schaal door veel mensen wordt gebruikt. Wanneer u een wijziging als het bovenstaande moet aanbrengen en directe toegang van het veld instelt om de code van alle mensen die dit veld gebruiken, zal breken.
Getters gebruiken en setters gaat over de toekomstige planning van de code, het maakt het flexibeler. Natuurlijk kunt u openbare velden gebruiken, vooral voor eenvoudige klassen die gewoon enkele gegevens bevatten. Maar het is altijd een goed idee om gewoon het veld privé te maken en codeert een krijgde en ingestelde methode ervoor.
Antwoord 15
Dit antwoord wordt samengevoegd van een andere vraag.
Uw getAge()-methode wordt een exemplaarmethode in Java genoemd.
Om een instantiemethode aan te roepen, moet u een doel van de klasse hebben waarin deze methode is gedefinieerd.
Bijvoorbeeld, als deze methode in een klasse met de naam Personstaat, dan
-
Maak een persoonsobject met de nieuwe operator
Person p = new Person(); -
Gebruik deze methode om de leeftijd van een
Person-object te krijgenp.getAge()