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

Vom Standpunkt der Objektorientierung aus betrachtet, können beide Alternativen der Wartung des Codes schaden, da sie die Kapselung der Klassen schwächen. Für eine Diskussion können Sie sich diesen ausgezeichneten Artikel ansehen: http://typicalprogrammer.com/?p=23

Answer 2

Getter- und Setter-Methoden sind Accessor-Methoden, d.h. sie sind im Allgemeinen eine öffentliche Schnittstelle, um private Klassenmitglieder zu ändern. Sie verwenden Getter- und Setter-Methoden, um eine Eigenschaft zu definieren. Sie greifen auf Getter- und Setter-Methoden als Eigenschaften außerhalb der Klasse zu, auch wenn Sie sie innerhalb der Klasse als Methoden definieren. Diese Eigenschaften außerhalb der Klasse können einen anderen Namen haben als der Eigenschaftsname in der Klasse.

Die Verwendung von Getter- und Setter-Methoden hat einige Vorteile, wie z. B. die Möglichkeit, Mitglieder mit komplexen Funktionen zu erstellen, auf die Sie wie auf Eigenschaften zugreifen können. Außerdem können Sie damit schreibgeschützte und schreibgeschützte Eigenschaften erstellen.

Auch wenn Getter- und Setter-Methoden nützlich sind, sollten Sie darauf achten, sie nicht übermäßig zu verwenden, da sie unter anderem die Codepflege in bestimmten Situationen erschweren können. Außerdem ermöglichen sie den Zugriff auf Ihre Klassenimplementierung, wie öffentliche Mitglieder. Die OOP-Praxis rät vom direkten Zugriff auf Eigenschaften innerhalb einer Klasse ab.

Wenn Sie Klassen schreiben, sollten Sie so viele Ihrer Instanzvariablen wie möglich privat machen und entsprechend Getter- und Setter-Methoden hinzufügen. Es gibt nämlich einige Situationen, in denen Sie nicht möchten, dass Benutzer bestimmte Variablen in Ihren Klassen ändern. Wenn Sie beispielsweise eine private statische Methode haben, die die Anzahl der für eine bestimmte Klasse erstellten Instanzen verfolgt, möchten Sie nicht, dass ein Benutzer diesen Zähler mithilfe von Code ändert. Nur die Konstruktoranweisung sollte diese Variable bei jedem Aufruf inkrementieren. In dieser Situation könnten Sie eine private Instanzvariable erstellen und eine Getter-Methode nur für die Zählervariable zulassen, was bedeutet, dass die Benutzer den aktuellen Wert nur mit der Getter-Methode abrufen können und nicht in der Lage sind, mit der Setter-Methode neue Werte zu setzen. Das Erstellen eines Getters ohne einen Setter ist eine einfache Möglichkeit, bestimmte Variablen in Ihrer Klasse schreibgeschützt zu machen.

Answer 3

Eine andere Verwendung (in Sprachen, die Eigenschaften unterstützen) ist, dass Setter und Getter andeuten können, dass eine Operation nicht trivial ist. In der Regel möchte man vermeiden, in einer Eigenschaft etwas zu tun, was rechenintensiv ist.

Answer 4

Ein relativ moderner Vorteil von Gettern/Settern ist, dass sie das Durchsuchen von Code in getaggten (indizierten) Code-Editoren erleichtern. Wenn Sie z.B. sehen wollen, wer ein Element setzt, können Sie die Aufrufhierarchie des Setters öffnen.

Ist das Mitglied hingegen öffentlich, ist es mit den Tools nicht möglich, den Lese-/Schreibzugriff auf das Mitglied zu filtern. Sie müssen sich also durch alle Verwendungen des Mitglieds kämpfen.

Answer 5

Außerdem dient dies der "Zukunftssicherheit" Ihrer Klasse. Insbesondere der Wechsel von einem Feld zu einer Eigenschaft ist ein ABI-Break. Wenn Sie also später entscheiden, dass Sie mehr Logik als nur "set/get the field" benötigen, dann müssen Sie die ABI brechen, was natürlich Probleme für alles andere schafft, das bereits gegen Ihre Klasse kompiliert wurde.