Warum Getter und Setter/Accessors verwenden?

Question

Was ist der Vorteil der Verwendung von Gettern und Settern - die nur abfragen und setzen - anstatt einfach öffentliche Felder für diese Variablen zu verwenden?

Wenn Getter und Setter jemals mehr tun als nur das einfache Get/Set, kann ich dies sehr schnell herausfinden, aber ich bin nicht 100% klar, wie:

public String foo;

schlechter ist als:

private String foo;
public void setFoo(String foo) { this.foo = foo; }
public String getFoo() { return foo; }

Ersteres hingegen erfordert viel weniger Standardcode.

Answer 1

Dafür gibt es viele Gründe. Mein Lieblingsgrund ist, wenn Sie das Verhalten ändern oder regeln müssen, was Sie auf eine Variable setzen können. Nehmen wir zum Beispiel an, Sie hätten eine Methode setSpeed(int speed). Sie möchten aber, dass Sie nur eine Höchstgeschwindigkeit von 100 einstellen können. Sie würden etwas tun wie:

public void setSpeed(int speed) {
  if ( speed > 100 ) {
    this.speed = 100;
  } else {
    this.speed = speed;
  }
}

Was wäre nun, wenn Sie überall in Ihrem Code das öffentliche Feld verwenden und dann feststellen, dass Sie die obige Anforderung benötigen? Viel Spaß bei der Suche nach jeder Verwendung des öffentlichen Feldes, anstatt nur Ihren Setter zu ändern.

Meine 2 Cents :)

Answer 2

Ein Vorteil von Accessors und Mutators ist, dass Sie eine Validierung durchführen können.

Zum Beispiel, wenn foo öffentlich war, konnte ich es einfach auf null und dann könnte jemand anderes versuchen, eine Methode des Objekts aufzurufen. Aber es ist nicht mehr da! Mit einer setFoo Methode konnte ich sicherstellen, dass foo wurde nie auf null .

Accessoren und Mutatoren ermöglichen auch die Kapselung - wenn Sie den Wert nicht sehen sollen, sobald er gesetzt ist (vielleicht wird er im Konstruktor gesetzt und dann von Methoden verwendet, aber er soll nie geändert werden), wird er nie von jemandem gesehen. Wenn Sie jedoch anderen Klassen erlauben können, ihn zu sehen oder zu ändern, können Sie den entsprechenden Accessor und/oder Mutator bereitstellen.

Answer 3

Danke, das hat mir wirklich Klarheit verschafft. Jetzt ist hier (fast) 10 (fast) gute Gründe NICHT zu verwenden, Getter und Setter:

1. Wenn Sie merken, dass Sie mehr tun müssen als nur den Wert zu setzen und zu holen, können Sie das Feld einfach privat machen, was Ihnen sofort zeigt, wo Sie direkt darauf zugegriffen haben.

2. Jede Validierung, die Sie dort durchführen, kann nur kontextfrei sein, was in der Praxis selten der Fall ist.

3. Sie können den eingestellten Wert ändern - dies ist ein absoluter Albtraum, wenn der Aufrufer Ihnen einen Wert übergibt, den Sie [Schock Horror] so speichern sollen, wie er ist.

4. Sie können die interne Darstellung ausblenden - fantastisch, Sie stellen also sicher, dass all diese Operationen symmetrisch sind, richtig?

5. Sie haben Ihre öffentliche Schnittstelle gegen Änderungen unter der Folie isoliert - wenn Sie eine Schnittstelle entworfen haben und sich nicht sicher waren, ob ein direkter Zugriff auf etwas in Ordnung ist, hätten Sie weiter entwerfen sollen.

6. Einige Bibliotheken erwarten dies, aber nicht viele - Reflection, Serialisierung, Mock-Objekte funktionieren alle sehr gut mit öffentlichen Feldern.

7. Wenn Sie diese Klasse erben, können Sie die Standardfunktionalität außer Kraft setzen - mit anderen Worten, Sie können den Aufrufer wirklich verwirren, indem Sie nicht nur die Implementierung verbergen, sondern sie auch inkonsistent machen.

Die letzten drei lasse ich einfach stehen (N/A oder D/C)...

Answer 4

Das hängt von Ihrer Sprache ab. Sie haben dies als "objektorientiert" und nicht als "Java" bezeichnet, daher möchte ich darauf hinweisen, dass die Antwort von ChssPly76 sprachabhängig ist. In Python zum Beispiel gibt es keinen Grund, Getter und Setter zu verwenden. Wenn Sie das Verhalten ändern müssen, können Sie eine Eigenschaft verwenden, die einen Getter und Setter um den grundlegenden Attributzugriff wickelt. Etwa so:

 class Simple(object):
   def _get_value(self):
       return self._value -1

   def _set_value(self, new_value):
       self._value = new_value + 1

   def _del_value(self):
       self.old_values.append(self._value)
       del self._value

   value = property(_get_value, _set_value, _del_value)

Answer 5

EDIT: Ich habe diese Frage beantwortet, weil eine Reihe von Leuten, die das Programmieren lernen, diese Frage stellen, und die meisten Antworten sind technisch sehr kompetent, aber sie sind nicht so leicht zu verstehen, wenn man ein Neuling ist. Wir waren alle Neulinge, also dachte ich, ich versuche mich an einer anfängerfreundlicheren Antwort.

Die beiden wichtigsten davon sind Polymorphismus und Validierung. Selbst wenn es nur eine dumme Datenstruktur ist.

Nehmen wir an, wir haben diese einfache Klasse:

public class Bottle {
  public int amountOfWaterMl;
  public int capacityMl;
}

Eine sehr einfache Klasse, die angibt, wie viel Flüssigkeit sich in ihr befindet und welches Fassungsvermögen sie hat (in Millilitern).

Was passiert, wenn ich das tue:

Bottle bot = new Bottle();
bot.amountOfWaterMl = 1500;
bot.capacityMl = 1000;

Nun, Sie würden nicht erwarten, dass das funktioniert, oder? Sie wollen, dass es eine Art Sicherheitskontrolle gibt. Und schlimmer noch, was wäre, wenn ich nie die maximale Kapazität angegeben hätte? Oh je, wir haben ein Problem.

Aber es gibt noch ein weiteres Problem. Was wäre, wenn Flaschen nur eine Art von Behälter wären? Was wäre, wenn wir mehrere Behälter hätten, alle mit unterschiedlichen Kapazitäten und Flüssigkeitsmengen? Wenn wir nur eine Schnittstelle schaffen könnten, könnten wir den Rest unseres Programms diese Schnittstelle akzeptieren lassen, und Flaschen, Kanister und alles Mögliche würden einfach austauschbar funktionieren. Wäre das nicht besser? Da Schnittstellen Methoden erfordern, ist das auch eine gute Sache.

Das Ergebnis wäre dann etwa so:

public interface LiquidContainer {
  public int getAmountMl();
  public void setAmountMl(int amountMl);
  public int getCapacityMl();
}

Großartig! Und jetzt ändern wir Bottle einfach in das hier:

public class Bottle extends LiquidContainer {
  private int capacityMl;
  private int amountFilledMl;

  public Bottle(int capacityMl, int amountFilledMl) {
    this.capacityMl = capacityMl;
    this.amountFilledMl = amountFilledMl;
    checkNotOverFlow();
  }

  public int getAmountMl() {
    return amountFilledMl;
  }

  public void setAmountMl(int amountMl) {
     this.amountFilled = amountMl;
     checkNotOverFlow();
  }
  public int getCapacityMl() {
    return capacityMl;
  }

  private void checkNotOverFlow() {
    if(amountOfWaterMl > capacityMl) {
      throw new BottleOverflowException();
    }
}

Ich überlasse die Definition der BottleOverflowException dem Leser als Übung.

Beachten Sie nun, wie viel robuster dies ist. Wir können jetzt mit jeder Art von Container in unserem Code umgehen, indem wir LiquidContainer anstelle von Bottle akzeptieren. Und wie diese Flaschen mit dieser Art von Dingen umgehen, kann ganz unterschiedlich sein. Sie können Flaschen haben, die ihren Zustand auf die Festplatte schreiben, wenn er sich ändert, oder Flaschen, die in SQL-Datenbanken oder GNU weiß was sonst noch speichern.

Und all diese können auf unterschiedliche Art und Weise mit verschiedenen Unglücken umgehen. Die Flasche prüft einfach, und wenn sie überläuft, löst sie eine RuntimeException aus. Aber das könnte der falsche Weg sein. (Es gibt eine nützliche Diskussion über die Fehlerbehandlung, aber ich halte sie hier absichtlich sehr einfach. In den Kommentaren werden die Leute wahrscheinlich auf die Schwächen dieses simplen Ansatzes hinweisen ;) )

Und ja, es scheint, dass wir von einer sehr einfachen Idee schnell zu viel besseren Antworten kommen.

Bitte beachten Sie auch, dass Sie das Fassungsvermögen einer Flasche nicht ändern können. Sie ist jetzt in Stein gemeißelt. Sie könnten dies mit einem int tun, indem Sie ihn für endgültig erklären. Aber wenn es sich um eine Liste handeln würde, könnte man sie leeren, neue Dinge hinzufügen und so weiter. Man kann den Zugriff nicht darauf beschränken, die Innereien zu berühren.

Es gibt noch eine dritte Sache, die noch nicht jeder angesprochen hat: Getter und Setter verwenden Methodenaufrufe. Das bedeutet, dass sie wie normale Methoden aussehen, wie überall sonst auch. Anstatt eine seltsame spezifische Syntax für DTOs und so zu haben, hat man überall das Gleiche.