Was ist der Sinn von Setzen und Gettern in Java? [Duplikat

StackOverflow https://stackoverflow.com/questions/1461598

Frage

Diese Frage hat hier bereits eine Antwort:

Bitte verzeihen Sie die Länge, aber hier sind zwei Programme, beide genau gleich, aber eine mit und eine ohne Setter, Getters und Konstrukteure.

Ich habe schon einmal eine grundlegende C ++ - Klasse genommen und erinnere mich nicht an eine davon, und im Moment sehe ich den Sinn von ihnen nicht, wenn jemand sie in Lamens Bedingungen erklären könnte, würde ich es sehr zu schätzen wissen. In dem Moment, in dem sie nichts anderes als Raumverschwender zu sein scheinen, um meinen Code länger aussehen zu lassen, aber der Lehrer sagt, dass sie wichtig sind (und bisher ist das).

Danke im Voraus! Und jetzt ist hier der Code: mileage.java:

package gasMileage;

import java.util.Scanner; //program uses class Scanner

public class Mileage 
{
    public int restart;
    public double miles, gallons, totalMiles, totalGallons, milesPerGallon;
    public Mileage(int newRestart, double newMiles, double newGallons, 
                   double newTotalMiles, double newTotalGallons, double newMilesPerGallon)
    {
        setRestart(newRestart);
        setMiles(newMiles);
        setGallons(newGallons);
        setTotalMiles(newTotalMiles);
        setTotalGallons(newTotalGallons);
        setMilesPerGallon(newMilesPerGallon);
    }
    public void setRestart(int newRestart)
    {
        restart = newRestart;
    }
    public int getRestart()
    {
        return restart;
    }
    public void setMiles(double newMiles)
    {
        miles = newMiles;
    }
    public double getMiles()
    {
        return miles;
    }
    public void setGallons(double newGallons)
    {
        gallons = newGallons;
    }
    public double getGallons()
    {
        return gallons;
    }
    public void setTotalMiles(double newTotalMiles)
    {
        totalMiles = newTotalMiles;
    }
    public double getTotalMiles()
    {
        return totalMiles;
    }
    public void setTotalGallons(double newTotalGallons)
    {
        totalGallons = newTotalGallons;
    }
    public double getTotalGallons()
    {
        return totalGallons;
    }
    public void setMilesPerGallon(double newMilesPerGallon)
    {
        milesPerGallon = newMilesPerGallon;
    }
    public double getMilesPerGallon()
    {
        return milesPerGallon;
    }
    public void calculateMileage()
    {
        Scanner input = new Scanner(System.in);
        while(restart == 1)
        {
            System.out.print("Please input number of miles you drove: ");
            miles = input.nextDouble();
            totalMiles = totalMiles + miles;
            System.out.print("Please input number of gallons you used: ");
            gallons = input.nextDouble();
            totalGallons = totalGallons + gallons;
            milesPerGallon = miles / gallons;
            System.out.printf("Your mileage is %.2f MPG.\n", milesPerGallon);
            System.out.print("Would you like to try again? 1 for yes, 2 for no: ");
            restart = input.nextInt();
        }
        milesPerGallon = totalMiles / totalGallons;
        System.out.printf("Your total mileage for these trips is: %.2f.\nYour total gas consumed on these trips was: %.2f.\n", totalMiles, totalGallons);
        System.out.printf("Your total mileage for these trips is: %.2f MPG", milesPerGallon);
    }
}

Milegetest.java:

package gasMileage;

public class Mileagetest 
{
    public static void main(String[] args) 
    {
        Mileage myMileage = new Mileage(1,0,0,0,0,0);
        myMileage.calculateMileage();
    }
}

Und jetzt für den ohne Setter und Getter:

Testmileage.java:

package gasMileage;

import java.util.Scanner;

public class Testmileage 
{
    int restart = 1;
    double miles = 0, milesTotal = 0, gas = 0, gasTotal = 0, mpg = 0;
    Scanner input = new Scanner(System.in);
    public void testCalculate()
    {
        while(restart == 1)
        {
            System.out.print("Please input miles: ");
            miles = input.nextDouble();
            milesTotal = milesTotal + miles;
            System.out.print("Please input gas: ");
            gas = input.nextDouble();
            gasTotal = gasTotal + gas;
            mpg = miles/gas;
            System.out.printf("MPG: %.2f", mpg);
            System.out.print("\nContinue? 1 = yes, 2 = no: ");
            restart = input.nextInt();
        }
            mpg = milesTotal / gasTotal;
            System.out.printf("Total Miles: %.2f\nTotal Gallons: %.2f\nTotal MPG: %.2f\n", milesTotal, gasTotal, mpg);
    }
}

Testmileagest.java:

package gasMileage;

public class Testmileagetest 
{

    /**
     * @param args
     */
    public static void main(String[] args) 
    {
        Testmileage test = new Testmileage();
        test.testCalculate();
    }

}

Danke noch einmal!

War es hilfreich?

Lösung

Der Punkt von Gettern und Setter,, Unabhängig von der Sprache, ist, die zugrunde liegende Variable zu verbergen. Auf diese Weise können Sie die Überprüfungslogik hinzufügen, wenn Sie versuchen, einen Wert festzulegen. Wenn Sie beispielsweise ein Feld für ein Geburtsdatum hatten, möchten Sie möglicherweise nur zulassen, dass dieses Feld in der Vergangenheit in der Vergangenheit festgelegt wird. Dies kann nicht erzwungen werden, wenn das Feld öffentlich zugänglich und modifizierbar ist - Sie benötigen die Getter und Setter.

Auch wenn Sie noch keine Überprüfung benötigen, brauchen Sie sie möglicherweise in Zukunft. Das Schreiben der Getter und Setter bedeutet jetzt, dass die Schnittstelle konsistent gehalten wird. Daher wird vorhandener Code nicht brechen, wenn Sie ihn ändern.

Andere Tipps

Die anderen Antworten geben im Allgemeinen eine gute Vorstellung von einigen Gründen für die Verwendung von Getter und Setter, aber ich möchte ein etwas vollständiges Beispiel dafür geben, warum sie nützlich sind.

Nehmen wir zum Beispiel eine Datei (ignorieren die Existenz von a File Klasse in Java). Dies File Die Klasse hat ein Feld zum Speichern des Typs der Datei (.pdf, .exe, .txt usw.) ... Wir werden alles andere ignorieren.

Zunächst beschließen Sie, es als aufzubewahren String Ohne Getters und Setter:

public class File {
   // ...
   public String type;
   // ...
}

Hier sind einige Probleme mit der Verwendung von Gettern und Setter.

Keine Kontrolle darüber, wie das Feld festgelegt ist:

Alle Kunden Ihrer Klasse können damit tun, was sie wollen:

public void doSomething(File file) {
   // ...
   file.type = "this definitely isn't a normal file type";
   // ...
}

Sie entscheiden später, dass Sie wahrscheinlich nicht möchten, dass sie das tun ... aber da sie direkten Zugriff auf das Feld in Ihrer Klasse haben, haben Sie keine Möglichkeit, es zu verhindern.

Unfähigkeit, die interne Darstellung leicht zu ändern:

Später entscheiden Sie, dass Sie den Dateityp als Instanz einer Schnittstelle namens speichern möchten FileType, sodass Sie ein Verhalten mit verschiedenen Dateitypen in Verbindung bringen können. Viele Kunden Ihrer Klasse rufen jedoch bereits Dateitypen ab und setzen Strings. Sie hätten also ein Problem dort ... Sie würden viel Code brechen (sogar Code in anderen Projekten, die Sie nicht beheben können, wenn es sich um eine Bibliothek handelt), wenn Sie das Feld nur von einem geändert haben String zu einem FileType.

Wie Getter und Setter dies lösen

Stellen Sie sich nun vor, Sie hatten stattdessen das Feld Typ gemacht private und erstellt

public String getType() {
   return this.type;
}

public void setType(String type) {
   this.type = type;
}

Kontrolle über das Einstellen der Eigenschaft:

Wenn Sie nun eine Anforderung implementieren möchten, dass nur bestimmte Zeichenfolgen gültige Dateitypen sind und andere Zeichenfolgen verhindern, können Sie einfach schreiben:

public void setType(String type) {
   if(!isValidType(type)) {
       throw new IllegalArgumentException("Invalid file type: " + type);
   }
   this.type = type;
}

private boolean isValidType(String type) {
   // logic here
}

Fähigkeit, die interne Darstellung leicht zu ändern:

Wechseln String Die Darstellung des Typs ist relativ einfach. Stellen Sie sich vor, Sie haben eine enum ValidFileType was implementiert FileType und enthält die gültigen Arten von Dateien.

Sie können die interne Darstellung des Dateityps in der Klasse wie folgt leicht ändern:

public class File {
   // ...
   private FileType type;
   // ...
   public String getType() {
      return type.toString();
   }

   public void setType(String type) {
      FileType newType = ValidFileType.valueOf(type);

      if(newType == null) {
         throw new IllegalArgumentException("Invalid file type: " + type);
      }

      this.type = newType;
   }
}

Seit Kunden der Klasse haben angerufen getType() und setType() Wie auch immer, nichts ändert sich aus ihrer Sicht. Nur die Interna der Klasse haben sich geändert, nicht die Schnittstelle, die andere Klassen verwenden.

Verkapselung

Accessor -Methoden ("Setzer und Getter") versuchen, die Details darüber zu verbergen, wie die Daten in einem Objekt gespeichert werden. In der Praxis sind sie ein verherrlichtes Mittel, um Daten in nicht orientierter Weise zu speichern und abzurufen. Accessors verkapulieren nichts in der Lage, dass zwischen den folgenden zwei Codeteilen wenig praktische Unterschiede gibt:

Person bob = new Person();
Colour hair = bob.getHairColour();
hair.setRed( 255 );

Und das:

Person bob = new Person();
Colour hair = bob.hairColour;
hair.red = 255;

Beide Code -Snippets enthüllen die Idee, dass eine Person eng mit dem Haar gekoppelt ist. Diese enge Kopplung zeigt sich dann in der gesamten Codebasis, was zu einer spröden Software führt. Das heißt, es wird schwierig zu ändern, wie das Haar einer Person gespeichert wird.

Stattdessen:

Person bob = new Person();
bob.setHairColour( Colour.RED );

Dies folgt der Prämisse von "Tell, nicht fragen". Mit anderen Worten sollten Objekte (von anderen Objekten) angewiesen werden, eine bestimmte Aufgabe auszuführen. Dies ist der springende Punkt der objektorientierten Programmierung. Und nur sehr wenige Leute scheinen es zu verstehen.

Der Unterschied zwischen den beiden Szenarien ist Folgendes:

  • In der ersten Situation hatte Bob keine Kontrolle darüber, welche Farbe seine Haare werden würden. Ideal für einen Friseur mit einer Vorliebe für Rothaarige, nicht so gut für Bob, der diese Farbe verachtet.
  • In der zweiten Situation hat Bob die vollständige Kontrolle darüber, was sein Haar sein wird, weil kein anderes Objekt im System diese Farbe ohne Bobs Erlaubnis ändern darf.

Eine andere Möglichkeit, dieses Problem zu vermeiden, besteht darin, eine Kopie von Bobs Haarfarbe (als neue Instanz) zurückzugeben, die nicht mehr an Bob gekoppelt ist. Ich finde, dass es eine unelegante Lösung darstellt, weil es Verhalten gibt, dass eine andere Klasse mit der Haare einer Person nicht mehr mit der Person selbst verbunden ist. Dies verringert die Fähigkeit, Code wiederzuverwenden, was zu einem doppelten Code führt.

Verstecken von Datentypen

In Java, das nicht zwei Methodensignaturen haben können, die nur durch Rückgabetyp unterscheiden, verbergt es den vom Objekt verwendeten zugrunde liegenden Datentyp nicht. Sie werden, wenn überhaupt, selten Folgendes sehen:

public class Person {
  private long hColour = 1024;

  public Colour getHairColour() {
    return new Colour( hColour & 255, hColour << 8 & 255, hColour << 16 & 255 );
  }
}

In der Regel haben die einzelnen Variablen ihren Datentyp mithilfe des entsprechenden Accessors ausgesetzt wörtlich ausgesetzt und benötigt das Refactoring, um ihn zu ändern:

public class Person {
  private long hColour = 1024;

  public long getHairColour() {
    return hColour;
  }

  /** Cannot exist in Java: compile error. */
  public Colour getHairColour() {
    return new Colour( hColour & 255, hColour << 8 & 255, hColour<< 16 & 255 );
  }
}

Während es einen Abstraktionsniveau liefert, ist es ein dünner Schleier, der nichts für eine lockere Kopplung tut.

Sagen Sie, fragen Sie nicht

Weitere Informationen zu diesem Ansatz finden Sie unter Lesen Sagen Sie, fragen Sie nicht.

Dateibeispiel

Betrachten Sie den folgenden Code, der aus Colinds Antwort leicht modifiziert wurde:

public class File {
   private String type = "";

   public String getType() {
      return this.type;
   }

   public void setType( String type ) {
      if( type = null ) {
        type = "";
      }

      this.type = type;
   }

   public boolean isValidType( String type ) {
      return getType().equalsIgnoreCase( type );
   }
}

Die Methode getType() In diesem Fall ist überflüssig und führt unweigerlich (in der Praxis) zu einem doppelten Code wie:

public void arbitraryMethod( File file ) {
  if( file.getType() == "JPEG" ) {
    // Code.
  }
}

public void anotherArbitraryMethod( File file ) {
  if( file.getType() == "WP" ) {
    // Code.
  }
}

Ausgaben:

  • Datentyp. Das type Das Attribut kann nicht leicht von einer Zeichenfolge zu einer Ganzzahl (oder einer anderen Klasse) wechseln.
  • Implizite Protokoll. Es ist zeitaufwändig, den Typ aus dem spezifischen zu abstrakt (PNG, JPEG, TIFF, EPS) an den General (IMAGE, DOCUMENT, SPREADSHEET).
  • Führt Fehler ein. Das Ändern des implizierten Protokolls erzeugt keinen Compiler -Fehler, der zu Fehler führen kann.

Vermeiden Sie das Problem insgesamt, indem Sie andere Klassen verhindern fragen für Daten:

public void arbitraryMethod( File file ) {
  if( file.isValidType( "JPEG" ) ) {
    // Code.
  }
}

Dies impliziert das Ändern der get Accessor -Methode zu private:

public class File {
   public final static String TYPE_IMAGE = "IMAGE";

   private String type = "";

   private String getType() {
      return this.type;
   }

   public void setType( String type ) {
      if( type == null ) {
        type = "";
      }
      else if(
        type.equalsIgnoreCase( "JPEG" ) ||
        type.equalsIgnoreCase( "JPG" ) ||
        type.equalsIgnoreCase( "PNG" ) ) {
        type = File.TYPE_IMAGE;
      }

      this.type = type;
   }

   public boolean isValidType( String type ) {
      // Coerce the given type to a generic type.
      //
      File f = new File( this );
      f.setType( type );

      // Check if the generic type is valid.
      //
      return isValidGenericType( f.getType() );
   }
}

Kein anderer Code im System wird brechen, wenn die File Die Klasse übergeht das implizite Protokoll von bestimmten Typen (z. B. JPEG) auf generische Typen (z. B. Bild). Der gesamte Code im System muss die verwenden isValidType Methode, die den Typ dem aufrufenden Objekt nicht gibt, sondern erzählt das File Klasse, um einen Typ zu validieren.

Die Idee ist, dass Sie, wenn Ihre Kundenklassen Get-/Set -Funktionen anrufen, das, was sie später tun, ändern können und die Anrufer isoliert sind. Wenn Sie eine öffentliche Variable haben und ich direkt darauf zugreife, gibt es keine Möglichkeit, dass Sie später ein Verhalten hinzufügen, wenn sie zugegriffen oder festgelegt werden.

Selbst in Ihrem einfachen Beispiel könnten Sie es mehr nutzen.

Anstatt zu verwenden:

milesPerGallon = miles / gallons;

in Calculatemileage ()

Sie können setMiles () und setgallons () ändern, um MilesPergallon zu aktualisieren, wenn sie angerufen wurden. Entfernen Sie dann setMilespergallon (), um anzuzeigen, dass es sich um eine schreibgeschützte Eigenschaft handelt.

Der Punkt ist, dass eine Klasse keinen direkten Zugriff auf ihre Felder zulassen sollte, da dies implementierungsspezifisch ist. Möglicherweise möchten Sie die Klasse später ändern, um einen anderen Datenspeicher zu verwenden, aber die Klasse für ihre "Benutzer" oder Sie können auch eine Schnittstelle erstellen, die auch keine Felder enthalten kann.

Schauen Sie sich das an die Wikipedia -Artikel zum Thema.

Sie bieten eine öffentliche Schnittstelle für Ihre Klasse und ein gewisses Maß an Kapselung. Überlegen Sie, wie Sie ohne Getter und Setter auf öffentliche Daten zugreifen würden.

Mileage m = new Mileage();
m.miles = 5.0;
m.gallons = 10.0;
...

Wenn Sie nun entscheiden, dass Sie Ihrer Klasse eine Bestätigung hinzufügen möchten, müssen Sie Ihren Code überall ändern, wo auf die Felder direkt zugegriffen wurden. Wenn Sie von Anfang an Getter und Setter verwenden (Nur wo sie benötigt werden) Sie können diese Anstrengung vermeiden und Ihren Code nur an einem Ort ändern.

Wenn Sie Getters und Setzer verwenden, können Sie die Implementierung später flexibel ändern. Sie denken vielleicht nicht, dass Sie das brauchen, aber manchmal tun Sie es. Sie möchten beispielsweise das Proxy -Muster verwenden, um ein Objekt zu laden, das teuer zu verwenden ist:

class ExpensiveObject {
    private int foo;

    public ExpensiveObject() {
       // Does something that takes a long time.
    }

    public int getFoo() { return foo; }
    public void setFoo(int i) { foo = i; }
}

class ExpensiveObjectProxy extends ExpensiveObject {
    private ExpensiveObject realObject;

    public ExpensiveObjectProxy() { ; }

    protected void Load() {
       if ( realObject == null ) realObject = new ExpensiveObject();
    }

    public int getFoo() { Load(); return realObject.getFoo(); }
    public void setFoo(int i) { Load(); realObject.setFoo(i); }
}

class Main {
    public static void main( string[] args ) {
         // This takes no time, since ExpensiveOjbect is not constructed yet.
         ExpensiveObject myObj = new ExpensiveObjectProxy();

         // ExpensiveObject is actually constructed here, when you first use it.
         int i = myObj.getFoo();
    }
}

Wo dies oft zum Spielen kommt, ist, wenn Sie Objekte über ein Orm zu Datenbanken zugeordnet sind. Sie laden nur die Dinge, die Sie benötigen, und kehren dann zur Datenbank zurück, um den Rest zu laden, wenn/wenn es tatsächlich verwendet wird.

Im Allgemeinen waren Setzer und Getter ein schlechter Hack der frühen GUI -Bauherren (Borland), um die Tatsache zu umgehen, dass alle Variablen privat sein sollten (wirklich ist dies unbedingt erforderlich)

Einige Leute nennen sie eine Abstraktion, aber sie sind es nicht. Ein Boilerplate Setter/Getter ist nicht besser als ein öffentliches Mitglied. Sie ermöglichen immer weiter ))

Getter und Setter fördern den Zugriff auf die Daten einer Klasse von außerhalb der Klasse. Jeder Code, der auf ein Mitglied einer Klasse zugreift, sollte wahrscheinlich innerhalb dieser Klasse (wie Ihre Entwurfsaussagen) vorhanden sein und daher keine Setter oder Getter benötigen. Sie sollten unnötig sein.

Es ist auch schrecklich, einen Setter in alle Ihre Klassen zu zwingen. Dies bedeutet, dass Ihre Klassen einfach nicht unveränderlich sein können, während Sie tatsächlich einen wirklich guten Grund haben sollten, eine Klasse veränderlich zu machen.

Trotzdem sind sie nützlich für Überschneidungsbedenken wie Persistenanzmotoren und GUI-Bauherren, bei denen sie Werte erhalten und festlegen können, und die Klasse kann überwachen, was sie erhalten oder geändert und ändern oder validieren kann.

Ein besseres Muster für die Systeme, die den Variablenzugriff für die Überschneidung benötigen, besteht darin, direkt durch Reflexion auf die Variable zuzugreifen, aber einen Setter oder Getter aufzurufen, wenn einer vorhanden ist-wenn möglich, wenn möglich, ist der Setter und Getter privat.

Auf diese Weise würde der Nicht-OO-Cross-Cuting-Code korrekt funktionieren, es würde Ihrer Klasse ermöglichen, Sätze zu ändern und zu erhalten, wenn er bei Bedarf Getter (die manchmal wirklich nützlich sind).

Der Punkt der Accessor -Methoden dh. Getters and Setters soll eine Kapselung an die Versteckung von Informationen bereitstellen. Es ist eines der Grundprinzipien der objektorientierten Programmierung.

Accessor -Methoden

Informationsversteck/Einkapselung

Die Antwort in einem Wort ist Schnittstellen.

Schnittstellen ermöglichen Methoden, nicht für Felder, daher besteht die festgelegte Übereinkommen, GetX- und SETX -Methoden für diesen Zweck zu haben.

(Und Schnittstellen ist der Weg, um die Funktionalität von der Implementierung in Java zu entkoppeln)

Ihr Beispiel ist bis zum Punkt der Absurdität extrem. Ja, all diese Getter und Setter bauen den Code auf und fügen in diesem Fall keinen Wert hinzu. Die zugrunde liegende Idee der Verkapselung ist jedoch für größere Systeme aus vielen interagierenden Komponenten gedacht, nicht für kleine, in sich geschlossene Programme.

Eigenschaften nützlicher, vernünftiger Verwendungen von Gettern und Settern:

  • Eine Klasse, die von vielen anderen Klassen verwendet wird (das Verstecken von Implementierungsdetails erleichtert es den Clients)
  • Getters und Setter nur für Felder, für die sie tatsächlich benötigt werden - so wenig wie möglich, die meisten Felder sollten privat und nur innerhalb ihrer Klasse verwendet werden
  • Sehr wenige Setzer im Allgemeinen: Veränderliche Felder machen es viel schwieriger, den Status des Programms im Auge zu behalten, als nur schreibgeschützte Felder
  • Getters und Setter, die eigentlich tatsächlich tun etwas anderes als auf einen Fett, z.

Ein paar Monate schnell vorwärts. Vielleicht fordert Ihr Lehrer Sie auf, eine Remote -Version der Kilometerklasse zu implementieren. Vielleicht als Webdienst vielleicht etwas anderes.

Ohne die Getter/Setter müssten Sie jeden Code überall ändern, der eine Kilometerleistung greift, und die Getter/Setter müssen Sie so ziemlich (in einer perfekten Welt) nur die Schaffung eines Kilometyps ändern.

Mit Getters und Setter können Sie nützliche Abkürzungen für den Zugriff auf und mutieren Daten innerhalb eines Objekts erstellen. Im Allgemeinen kann dies als Alternative zu zwei Funktionen mit einem Objekt angesehen werden, das verwendet wird, um einen Wert zu erhalten und festzulegen, wie SO:

{
    getValue: function(){
        return this._value;
    },
    setValue: function(val){
        this._value = val;
    }
}

Der offensichtliche Vorteil für das Schreiben von JavaScript auf diese Weise besteht darin, dass Sie ihn dunkle Werte verwenden können, auf die der Benutzer nicht direkt zugreifen soll. Ein Endergebnis, das ungefähr wie folgt aussieht (mit einem Verschluss, um den Wert eines neu konstruierten Feldes zu speichern):

function Field(val){
    var value = val;

    this.getValue = function(){
        return value;
    };

    this.setValue = function(val){
        value = val;
    };
}

Wenn Sie Setter- und Getter -Methoden hinzufügen, um den Status der verwalteten Bean zugänglich zu machen, müssen Sie Setter- und Getter -Methoden für diesen Zustand hinzufügen. Die Erstellungsmethode nennt die Bean -Greet -Methode, und die Getalutationsmethode ruft das Ergebnis ab. Sobald die Setter- und Getter -Methoden hinzugefügt wurden, ist die Bohne abgeschlossen. Der endgültige Code sieht so aus: Paketgrüße;

import javax.inject.Inject;
import javax.enterprise.context.RequestScoped;
import javax.inject.Named;

@Named
@RequestScoped
public class Printer {

    @Inject @Informal Greeting greeting;

    private String name;
    private String salutation;

    public void createSalutation() {
        this.salutation = greeting.greet(name);
    }

    public String getSalutation() {
        return salutation;
    }
    public String setName(String name) {
       this.name = name;
    }

    public String getName() {
       return name;
    }
}

Verkapselung und Code-Wiederverwendung-Fähigkeit ist die Schönheit der objektorientierten Programmierung. Wenn wir uns mit einigen sensiblen Daten in unserem Code befassen, deklarieren wir sie als private Datenfelder, dh wir verkapseln unsere Daten, damit niemand direkt darauf zugreifen kann. Jetzt muss jeder, der auf diese Datenfelder zugreifen möchte IE ein kontrollierter Zugriffsmechanismus zum Umgang mit sensiblen Datenfeldern. Das folgende Beispiel kann hilfreich sein, um den Vorteil und die Bedeutung von Setter und Geters zu verstehen.

  • Ich habe eine Klasse implementiert, in der ich die Tage variabel benutze.
  • In meiner Klasse kann niemand den Wert von Tagen mehr als 365 festlegen.
  • Jemand möchte von meiner Klasse erben. (Code-Wiederverwendbarkeit).
  • Wenn er nun den Wert von Tagen mehr als 365 betritt, wird die gesamte Funktionalität meiner Klasse scheitern.
  • Daher hätte ich die Tage als privates Datenfeld variabel deklarieren sollen.
  • Wenn ich jetzt das Datenfeld von Days als privat deklariert hätte, konnte niemand den Wert von Tagen mehr als 365 festlegen, da ich eine Setterfunktion mit genannten Einschränkungen für Eingaben implementiert hätte.
Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top