Warum die Verwendung von Getter und setter/Accessoren?

Es gibt tatsächlich viele gute Gründe zu prüfen, mit Accessoren anstatt direkt auszusetzen Felder einer Klasse - außer eben das argument der Kapselung und um zukünftige änderungen zu erleichtern.

Hier sind einige der Gründe, die mir bekannt sind:

• Kapselung von Verhalten im Zusammenhang mit abrufen oder festlegen der Eigenschaft - dies ermöglicht zusätzliche Funktionen (wie z.B. die Validierung) Hinzugefügt werden später schneller.
• Versteckt die interne Darstellung der Immobilie, während das aussetzen einer Eigenschaft mit einer alternativen Darstellung.
• Isolierende Ihre öffentliche Schnittstelle, die von Wandel -, um die öffentliche Schnittstelle unverändert bleiben, während die Umsetzung von änderungen ohne Auswirkungen auf die vorhandenen Verbraucher.
• Kontrolle der Lebensdauer und Speicher-management (Entsorgung) Semantik der Eigenschaft - besonders wichtig in nicht-verwalteten Speicher-Umgebungen (z.B. C++ oder Objective-C).
• Bietet eine debugging-interception-Punkt, wenn sich ein Eigentum ändert sich bei runtime - debugging, Wann und wo eine Eigenschaft geändert, um einen bestimmten Wert kann ziemlich schwierig, ohne diese in einigen Sprachen.
• Verbesserte Interoperabilität mit Bibliotheken, die entworfen sind, zu arbeiten, die gegen-Eigenschaft getter - /setter - Spott, Serialisierung und WPF in den Sinn kommen.
• So dass die Erben zu ändern, die Semantik, wie die Eigenschaft verhält und ausgesetzt ist, durch überschreiben der getter/setter-Methoden.
• So dass der getter/setter übergeben werden, um lambda-Ausdrücke eher als Werte.
• Getter und setter erlauben können unterschiedliche Zugriffsebenen - zum Beispiel die bekommen kann öffentlich sein, aber der Satz konnte geschützt werden.

InformationsquelleAutor LBushkin

Einem öffentlichen Feld ist nicht schlimmer als eine getter - /setter-pair-Mädchen, die nichts tut, außer die Rücksendung der Feld-und zugewiesen. Erstens, es ist klar, dass (in den meisten Sprachen) gibt es keinen funktionalen Unterschied. Irgendeinen Unterschied muss in anderen Faktoren, wie beispielsweise die Wartbarkeit oder Lesbarkeit.

Einen oft genannten Vorteil der getter - /setter-Paare, nicht. Es gibt diese Behauptung, dass Sie können ändern Sie die Implementierung und Ihre Kunden müssen nicht neu kompiliert werden. Angeblich, Set-Methoden ermöglichen das hinzufügen von Funktionen wie Validierung später auf und Ihre Kunden nicht einmal kennen müssen. Jedoch, hinzufügen von Validierung zu einem setter ist eine änderung der Voraussetzungen, eine Verletzung des vorhergehenden Vertrages, das war ganz einfach, "Sie können alles, was in hier, und Sie bekommen können, dass die gleiche Sache später aus dem getter".

So, jetzt, dass Sie brach den Vertrag, ändern Sie jede Datei in der codebase ist etwas, das sollten Sie tun wollen, nicht zu vermeiden. Wenn Sie es vermeiden, Sie machen die Annahme, dass der gesamte code davon ausgegangen, der Vertrag für diese Methoden war anders.

Sollte das nicht der Vertrag, dann die Schnittstelle ermöglichen den Kunden, um das Objekt in ungültige Zustände. , Dass das genaue Gegenteil der Kapselung Wenn das Feld konnte nicht richtig eingestellt werden, um alles von Anfang an, warum nicht die Validierung von Anfang an dabei?

Diese gleiche argument gilt auch für andere angebliche Vorteile dieser pass-through-getter/setter-Paare: wenn Sie später entscheiden, um den Wert zu ändern gesetzt ist, du brichst den Vertrag. Wenn Sie überschreiben die Standard-Funktionalität in einer abgeleiteten Klasse, in einer Art und Weise über ein paar Harmlose änderungen (wie die Protokollierung oder anderen nicht-beobachtbaren Verhalten), du brichst den Vertrag von der Basis-Klasse. Das ist ein Verstoß gegen das Liskov Substituierbarkeit-Prinzip, das als eines der Grundprinzipien der OO.

Wenn eine Klasse diese dumme Getter und setter für jedes Feld, dann ist es eine Klasse, die keine Invarianten auch immer, kein Vertrag. Ist das wirklich Objekt-orientierten design? Wenn alle die Klasse hat, ist diese Getter und setter, es ist nur eine dumme Daten Halter und stumm Daten-Inhaber sollten schauen, wie dumm die Daten-Inhaber:

class Foo {
public:
    int DaysLeft;
    int ContestantNumber;
};

Hinzufügen von pass-through-getter/setter-Paare diese Klasse fügt keinen Wert. Andere Klassen sollten aussagekräftige Operationen, nicht nur Vorgänge, die die Felder bereitstellen. Das ist, wie Sie definieren und pflegen Sie nützlich Invarianten.

Client: "Was kann ich tun mit einem Objekt dieser Klasse?"

Designer: "können Sie Lesen und schreiben mehrerer Variablen."

Client: "Oh... cool, denke ich?"

Gibt es Gründe für die Verwendung von Getter und setter, aber wenn diese Gründe nicht vorhanden, die getter/setter-Paare, die im Namen des falschen Kapselung Götter ist nicht eine gute Sache. Gültige Gründe, um Getter oder setter die Dinge oft erwähnt, als mögliche änderungen können Sie später, wie die Validierung oder die verschiedenen internen Darstellungen. Oder vielleicht der Wert sollte gelesen werden von Kunden, aber nicht schreibbar ist (zum Beispiel, Lesen Sie die Größe eines Wörterbuchs), so dass eine einfache get-Methode ist eine gute Wahl. Aber diese Gründe sollten da sein, wenn Sie die Wahl treffen, und nicht nur als ein Potenzial, was Sie wollen vielleicht später. Dies ist ein Fall von YAGNI (Sie ist nicht Gonna Es Brauchen).

InformationsquelleAutor R. Martinho Fernandes

Gibt es viele Gründe. Mein Favorit ist, wenn Sie Sie brauchen, um das Verhalten oder die Regeln, was Sie können auf eine variable. Zum Beispiel können sagen, Sie hatte eine setSpeed(int speed) - Methode. Aber Sie wollen, dass Sie nur eine maximale Geschwindigkeit von 100. Sie würde so etwas machen:

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

Was nun, wenn ÜBERALL in Ihrem code, den Sie mit dem öffentlichen Feld-und dann erkannte man, müssen die genannten Anforderungen? Haben Sie Spaß, die Jagd nach jeder Benutzung des öffentlichen Feld anstatt nur zu ändern von Ihren setter.

My 2 cents 🙂

InformationsquelleAutor Peter D

Einer der Vorteile von Accessoren und Mutatoren ist, können Sie die Validierung.

Zum Beispiel, wenn foo öffentlichkeit gab, konnte ich leicht einstellen, dass es null und dann jemand anderes könnte versuchen, rufen Sie eine Methode auf dem Objekt. Aber es ist nicht mehr da! Mit einem setFoo Methode, ich könnte dafür sorgen, dass foo war nie zu null.

Accessoren und Mutatoren auch ermöglichen Kapselung - wenn Sie nicht sehen sollte der Wert einmal seinen Satz (vielleicht ist es im Konstruktor und dann durch Methoden, aber nie soll geändert werden), es wird nie gesehen, von niemandem. Aber wenn Sie zulassen, dass andere Klassen zu sehen, oder ändern Sie es, Sie bieten die richtige accessor und/oder mutator.

InformationsquelleAutor Thomas Owens

Naja ich möchte nur hinzufügen, dass auch wenn Sie manchmal notwendig sind für die Verkapselung und den Schutz von Variablen/Objekte, wenn wir wollen, dass code eine echte Objekt-Orientiertes Programm, dann müssen wir STOPPEN ÜBERNUTZUNG DER ACCESSOREN, verursachen manchmal hängen wir eine Menge auf Sie wenn ist nicht wirklich notwendig und macht fast das gleiche, als wenn wir die Variablen public.

InformationsquelleAutor Jorge Aguilar

Ich weiß, es ist ein bisschen spät, aber ich denke, es gibt einige Leute, die interessiert sind, in der Leistung.

Ich habe mich ein wenig performance-test. Ich schrieb eine Klasse "NumberHolder", die gut, hält eine ganze Zahl. Sie können entweder Lesen, dass die ganze Zahl durch Verwendung der get-Methode
anInstance.getNumber() oder durch direkten Zugriff auf die Nummer durch anInstance.number. Mein programm liest die Anzahl 1,000,000,000 mal über beide Möglichkeiten. Dieser Prozess wiederholt sich fünf mal, und die Zeit gedruckt wird. Ich habe das folgende Ergebnis:

Time 1: 953ms, Time 2: 741ms
Time 1: 655ms, Time 2: 743ms
Time 1: 656ms, Time 2: 634ms
Time 1: 637ms, Time 2: 629ms
Time 1: 633ms, Time 2: 625ms

(Zeitpunkt 1 ist der direkte Weg, Zeit 2 ist der getter)

Sehen Sie die get-Methode ist (fast) immer einen Tick schneller. Dann habe ich versucht mit einer unterschiedlichen Anzahl von Zyklen. Statt 1 Mio, habe ich 10 Millionen und 0,1 Millionen.
Die Ergebnisse:

10 Millionen Zyklen:

Time 1: 6382ms, Time 2: 6351ms
Time 1: 6363ms, Time 2: 6351ms
Time 1: 6350ms, Time 2: 6363ms
Time 1: 6353ms, Time 2: 6357ms
Time 1: 6348ms, Time 2: 6354ms

Mit 10 Millionen Zyklen, die Zeiten sind fast die gleichen.
Hier sind 100 tausend (0,1 Millionen) Zyklen:

Time 1: 77ms, Time 2: 73ms
Time 1: 94ms, Time 2: 65ms
Time 1: 67ms, Time 2: 63ms
Time 1: 65ms, Time 2: 65ms
Time 1: 66ms, Time 2: 63ms

Auch mit unterschiedlichen Mengen von Zyklen, die get-Methode ist ein wenig schneller als der normale Weg. Ich hoffe das hat dir geholfen.

InformationsquelleAutor kangalioo

Verbrachte ich eine Weile und dachte über diese für die Java-Falle, und ich glaube, die wirklichen Gründe sind:

1. Code, um die Schnittstelle, nicht die Implementierung
2. Nur Schnittstellen festlegen Methoden, keine Felder

In anderen Worten, der einzige Weg, können Sie ein Feld angeben, in ein interface ist durch die Bereitstellung einer Methode für das schreiben eines neuen Wertes und eine Methode zum Lesen des aktuellen Wertes.

Diese Methoden sind die berüchtigten getter und setter....

InformationsquelleAutor Thorbjørn Ravn Andersen

Verwenden wir Getter und setter:

• für die Wiederverwendbarkeit
• um die Validierung in späteren Phasen der Programmierung

Getter-und setter-Methoden public sind Schnittstellen zum Zugriff auf Klassenelemente.

Kapselung mantra

Kapselung mantra ist, um Felder private und Methoden public.

Getter-Methoden: Wir bekommen Zugang zu privaten Variablen.

Setter-Methoden: Wir ändern können private Felder.

Obwohl die getter-und setter-Methoden nicht neue Funktionalität hinzufügen, ändern wir unseren Geist kommen später wieder, um zu machen, die Methode

• besser;
• sicherer; und
• schneller.

Überall einen Wert verwendet werden kann, eine Methode, die zurückgibt, die Wert Hinzugefügt werden kann. Statt:

int x = 1000 - 500

verwenden

int x = 1000 - class_name.getValue();

In juristischer Hinsicht

Nehmen wir an, wir müssen zum speichern der details dieses Person. Diese Person hat die Felder name, age und sex. Dies zu tun beinhaltet das erstellen Methoden für die name, age und sex. Wenn wir nun benötigen, erstellen Sie eine andere person, wird es notwendig, zu erstellen, die die Methoden für die name, age, sex alle immer wieder.

Statt dies zu tun, erstellen wir eine Bohne class(Person) mit getter-und setter-Methoden. Also morgen können wir nur die Objekte erstellen, die von dieser Bean class(Person class) Wann immer wir müssen zum hinzufügen einer neuen person (siehe die Abbildung). Also wir verwenden erneut die Felder und Methoden der bean-Klasse, die ist viel besser.

InformationsquelleAutor Devrath

In den Sprachen, die nicht unterstützen "Eigenschaften" (C++, Java) oder recompilierung von Kunden, beim ändern der Felder-Eigenschaften (C#), mit get/set-Methoden einfacher zu ändern. Zum Beispiel durch hinzufügen von Validierungslogik, um eine Methode setFoo nicht verlangen, dass sich die öffentliche Schnittstelle einer Klasse.

In den Sprachen, die Unterstützung der "realen" Eigenschaften (Python, Ruby, vielleicht Smalltalk?) es gibt keine Punkt-zu-get - /set-Methoden.

InformationsquelleAutor John Millikin

Eines der Grundprinzipien der OO-design: Kapselung!

Gibt es Ihnen viele Vorteile, einer davon ist, dass Sie können ändern Sie die Implementierung der get - /Set-hinter den kulissen, aber alle Verbraucher, die Wert sind, weiter zu arbeiten, solange der Datentyp bleibt die gleiche.

InformationsquelleAutor Justin Niessner

Sollten Sie verwenden, Getter und setter, wenn:

• Man sich mit etwas befasst, ist konzeptionell ein Attribut, aber:
  • Ihre Sprache keine Eigenschaften (oder einem ähnlichen Mechanismus, wie Tcl - variable Spuren), oder
  • Ihre Sprache ist die Unterstützung der Eigenschaft ist nicht ausreichend für diesen Anwendungsfall, oder
  • Ihre Sprache (oder manchmal auch Ihre framework) idiomatische Konventionen fördern Getter oder setter für diesen Anwendungsfall.

So ist dies sehr selten eine Allgemeine Frage OO; es ist eine Sprache-spezifische Frage, verschiedene Antworten für verschiedene Sprachen und verschiedene use-cases).

Vom OO-Theorie Sicht, Getter und setter sind nutzlos. Die Schnittstelle der Klasse ist, was er tut, nicht, was sein Zustand ist. (Wenn nicht, die du geschrieben hast die falsche Klasse.) In sehr einfachen Fällen, wo das, was eine Klasse tut, ist nur, z.B., stellen Sie einen Punkt in rechtwinkligen Koordinaten,* die Attribute sind Teil der Schnittstelle; Getter und setter nur cloud. Aber in alles, aber sehr einfachen Fällen, weder die Attribute noch die Getter und setter sind Teil der Schnittstelle.

Anders ausgedrückt: Wenn Sie glauben, dass die Verbraucher von Ihrer Klasse gar nicht wissen, dass Sie eine spam Attribut, viel weniger in der Lage, es zu ändern, wohl oder übel, dann gibt Ihnen ein set_spam Methode ist das Letzte, was Sie tun möchten.

_{* Auch für, einfach Klasse, die Sie nicht unbedingt wollen, es zulassen, dass die x und y Werte. Wenn das ist wirklich Klasse, sollte es nicht haben Methoden wie translate, rotate usw.? Wenn es nur eine Klasse, weil Sie Ihre Sprache nicht haben, records/structs/named Tupel, dann ist dies nicht wirklich eine Frage OO...}

Aber niemand ist jemals Allgemeine OO-design. Sie sind dabei design und Implementierung, die in einer bestimmten Sprache. Und in einigen Sprachen, Getter und setter sind weit Weg von nutzlos.

Wenn Ihre Sprache nicht die Eigenschaften haben, die dann der einzige Weg, etwas zu repräsentieren, das ist konzeptionell ein Attribut, aber tatsächlich berechnet oder validiert, etc., ist durch Getter und setter.

Selbst wenn Ihre Sprache nicht Eigenschaften haben, kann es Fälle geben, wo Sie sind unzureichend oder unangemessen. Zum Beispiel, wenn Sie möchten, dass Sie in Unterklassen zu kontrollieren, die Semantik eines Attributs, in Sprachen ohne dynamische Zugang, eine Unterklasse kann nicht ersetzen, eine berechnete Eigenschaft für ein Attribut.

Als für die "was will ich ändern meine Implementierung später?" - Frage (wiederholt sich mehrmals in verschiedenen Formulierungen in beiden OP ' s Frage und die akzeptierte Antwort): Wenn es sich wirklich um eine Reine Implementierung zu ändern, und Sie begann mit einem Attribut, können Sie es ändern, um eine Eigenschaft, ohne die Schnittstelle. Es sei denn, natürlich, Ihre Sprache nicht unterstützt. Also das ist wirklich genau der gleiche Fall wieder.

Es ist auch wichtig, um die Ausdrücke der Sprache (oder der Rahmen), die Sie verwenden. Wenn Sie schreiben, schönes Rubin-Stil-code in C#, jeder erfahrene C# - Entwickler, außer Sie wird Schwierigkeiten haben, es zu Lesen, und das ist schlecht. Einige Sprachen haben ein stärkeres Kulturen rund um Ihre Konventionen als andere.—und es kann kein Zufall sein, dass Java und Python, die sind an entgegengesetzten enden des Spektrums, wie idiomatische Getter sind, geschehen zu haben, zwei der stärksten Kulturen.

Jenseits der menschlichen Leserinnen und Leser, gibt es Bibliotheken und tools erwarten, dass Sie Folgen den Konventionen, und machen Ihr das Leben schwer, wenn Sie nicht. Anschließen der Interface Builder widgets, alles andere als ObjC Eigenschaften, oder der Nutzung bestimmter Java mocking-libraries ohne Getter, nur macht Ihr das Leben schwer. Wenn die Werkzeuge sind wichtig für Sie, nicht gegen Sie kämpfen.

InformationsquelleAutor abarnert

Code entwickelt sich. private ist groß, wenn Sie benötigen Daten, die Mitglied Schutz. Schließlich werden alle Klassen sollten eine Art "miniprograms", die haben eine gut definierte Schnittstelle , dass man nicht einfach die Schraube mit dem Innenleben von.

Sagte, software-Entwicklung ist nicht etwa festgelegt, dass die endgültige version der Klasse, als wenn Sie drücken einige Gusseisen-statue auf dem ersten Versuch. Während Sie mit ihm arbeiten, code ist mehr wie Lehm. Es entwickelt sich, wie Sie es zu entwickeln, und erfahren Sie mehr über die problem domain, die Sie für die Lösung sind. Während der Entwicklung können Klassen miteinander interagieren, als Sie sollten (Abhängigkeit, die Sie planen, um den Faktor aus), miteinander verschmelzen oder sich aufspalten. Also ich denke, die Debatte läuft darauf hinaus, die Menschen nicht wollen, um religiös zu schreiben

int getVar() const { return var ; }

So haben Sie:

doSomething( obj->getVar() ) ;

Statt

doSomething( obj->var ) ;

Ist nicht nur getVar() visuell laut, es gibt diese illusion, dass gettingVar() ist irgendwie ein komplexerer Vorgang, als es wirklich ist. Wie Sie (wie die Klasse writer) hinsichtlich der Heiligkeit des var ist besonders verwirrend, wenn ein Benutzer Ihrer Klasse, wenn es einen passthru-setter -- dann sieht es aus wie Sie setzen diese Tore zu "schützen", etwas, das Sie darauf bestehen, ist wertvoll, (die Heiligkeit var), aber dennoch sogar Sie zugeben, dass die var's Schutz nicht viel Wert durch die Möglichkeit für jedermann, einfach kommen und set var zu was auch immer Wert, den Sie möchten, ohne dass Sie selbst einsehen, was Sie tun.

Damit ich das Programm wie folgt (davon ausgehend, dass eine "agile" Ansatz, -- dh wenn ich code schreiben, nicht zu wissen genau, was Sie tun werden/haben keine Zeit oder Erfahrung, um zu planen eine aufwendige Wasserfall-Stil-Schnittstelle einstellen):

1) Beginnen Sie mit allen öffentlichen Mitglieder für basic-Objekte mit Daten und Verhalten. Dies ist der Grund, warum in allen mein C++ - "Beispiel" - code, den Sie bemerken mich mit struct statt class überall.

2) Wenn ein Objekt das interne Verhalten für ein Datenelement wird Komplex genug ist, (zum Beispiel, es mag eine interne std::list in irgendeine Art von Bestellung), accessor-Typ Funktionen geschrieben werden. Denn ich bin der Programmierung von mir selbst, dass ich nicht immer die Mitglied private richtigen Weg, aber irgendwo im Laufe der evolution der Klasse werden dem Mitglied "befördert" werden, um entweder protected oder private.

3) Klassen, die sind komplett ausgearbeitet und haben strenge Regeln über Ihre Struktur (ie Sie genau wissen, was Sie tun, und Sie sind nicht zu "ficken" (technischer Begriff) mit seinen Einbauten) werden die class Bezeichnung, default, private Mitglieder, und nur ein paar ausgewählte Mitglieder werden dürfen public.

Ich finde dieses Vorgehen ermöglicht es mir, zu vermeiden, dort zu sitzen und religiös zu schreiben getter/setter, wenn eine Menge von Daten, die Mitglieder kommen aus migriert, verschoben, usw werden. während der frühen Stadien einer Klasse ist evolution.

InformationsquelleAutor bobobobo

Einer anderen Verwendung (in Sprachen, die Unterstützung properties), die setter und Getter kann bedeuten, dass eine operation ist nicht-trivial. In der Regel möchten Sie vermeiden, etwas zu tun, das ist rechnerisch teuer, in einer Eigenschaft.

InformationsquelleAutor Jason Baker

Einem relativ modernen Vorteil der get - /Set-Methoden ist, dass macht es einfacher zu navigieren code in tagged (indexiert) code-Editoren. E. g. Wenn Sie möchten, um zu sehen, wer Mitglied ist, können Sie öffnen Sie die Aufrufhierarchie der setter.

Auf der anderen Seite, wenn das Mitglied der öffentlichkeit, die tools machen es nicht möglich zu filtern, Lesen/schreiben Zugriff auf das Element. So haben Sie zu stapfen, obwohl alle Verwendungen des Mitglieds.

InformationsquelleAutor Rakesh Singh

Darüber hinaus ist dies zu "future-proof" Ihrer Klasse. Insbesondere der Wechsel von einem Feld, einer Eigenschaft ist eine ABI-Pause, so dass, wenn Sie später entscheiden, dass Sie brauchen mehr Logik als nur "set/get the field", dann müssen Sie brechen ABI, was natürlich Probleme schafft, für alles andere bereits kompiliert gegen Ihre Klasse.

InformationsquelleAutor Pete