Ich weiß, es ist ein bisschen spät, aber ich denke, es gibt einige Leute, die sich für die Leistung interessieren.
Ich habe einen kleinen Leistungstest durchgeführt. Ich habe eine Klasse "NumberHolder" geschrieben, die, nun ja, einen Integer enthält. Sie können diesen Integer entweder mit der Getter-Methode lesen anInstance.getNumber()
oder durch direkten Zugriff auf die Nummer mit anInstance.number
. Mein Programm liest die Zahl 1.000.000.000 Mal, auf beiden Wegen. Dieser Vorgang wird fünfmal wiederholt und die Zeit wird ausgedruckt. Ich habe das folgende Ergebnis erhalten:
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
(Zeit 1 ist der direkte Weg, Zeit 2 ist der Getter)
Der Getter ist nämlich (fast) immer ein bisschen schneller. Dann habe ich es mit einer anderen Anzahl von Zyklen versucht. Anstelle von 1 Million habe ich 10 Millionen und 0,1 Millionen verwendet. 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
Bei 10 Millionen Zyklen sind die Zeiten fast identisch. 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 bei unterschiedlicher Anzahl von Zyklen ist der Getter etwas schneller als der normale Weg. Ich hoffe, das hat Ihnen geholfen.
8 Stimmen
@Dean J: D stackoverflow.com/search?q=getters+setters
10 Stimmen
Natürlich ist beides gleich schlecht, wenn das Objekt keine zu ändernde Eigenschaft benötigt. Ich würde lieber alles privat machen, und dann Getter hinzufügen, wenn es nützlich ist, und Setter, wenn es nötig ist.
31 Stimmen
Google "accessors are evil"
42 Stimmen
"Accessors sind böse", wenn Sie funktionalen Code oder unveränderliche Objekte schreiben. Wenn Sie zustandsbehaftete, veränderbare Objekte schreiben, dann sind sie ziemlich wichtig.
23 Stimmen
Erzählen, nicht fragen. pragprog.com/articles/tell-dont-ask
2 Stimmen
Mit Ausnahme von 6 und 8 würde ich es wagen zu sagen, dass keiner dieser Punkte in 99 % der Fälle zur Anwendung kommt. Dennoch würde ich gerne Java verwenden
String s = employee.name()
yemployee.name("oscar")
anstelle von getName() setName()1 Stimmen
@Oscar Reyes, ja, ich stimme zu, dass 6 und 8 meiner Erfahrung nach die beiden häufigsten sind. Das heißt, ich bevorzuge immer noch nicht mit der C#ish Syntax; mein alter Mann Gehirn wird verwirrt.
4 Stimmen
Ich bin überrascht, dass niemand über die Datensynchronisation spricht. Angenommen, Sie verwenden
public String foo;
es ist nicht fadensicher! Stattdessen können Sie definierenget
terset
ters mit Synchronisierungstechniken, um die Untreue von Daten zu vermeiden [d.h. ein anderer Thread, der das foo durcheinanderbringt]. Ich hielt es für erwähnenswert.3 Stimmen
@goldenparrot: Meistens ist die Synchronisierung einzelner Zugriffe auf ein Objekt viel zu ineffizient oder sogar anfällig für Synchronisierungsprobleme (wenn man mehrere Eigenschaften eines Objekts ändern muss sogleich ). IME, müssen Sie oft Operationen als Ganzes verpacken, die mehrere Zugriffe auf ein Objekt durchführen. Das kann nur durch Synchronisation auf der Seite der Benutzer eines Typs erreicht werden.
1 Stimmen
Fassen Sie Ihre Lieblingsstellen aus allen Antworten nicht in der Frage selbst zusammen. Dies ist eine Seite für Fragen und Antworten, kein Forum.
3 Stimmen
@ErikReppen was sollte ich lesen, um OOP überhaupt zu verstehen?
0 Stimmen
Es gibt auch das sehr wichtige Problem der gemeinsamen Nutzung von Code mit anderen, wenn Sie Objektfelder als Teile der externen Schnittstelle behandeln, die andere Leute nutzen können, dann könnte es unmöglich sein, das Feld in eine Funktion zu ändern, ohne Änderungen im Code anderer Leute zu zerstören.
0 Stimmen
@ErikReppen Danke für den Link, ich arbeite daran, zu verstehen, was OOP sein soll, aber es erweist sich als schwierig bei der Menge an Fehlinformationen, die im Umlauf sind. P.S. Ich finde auch, dass wikipedia eine der besten Quellen in vielen wissenschaftlichen Bereichen ist.
3 Stimmen
@TimoHuovinen es geht darum, nicht herausfinden zu müssen, welche von 500 Funktionen tatsächlich einen Wert ändert. Man macht einen Wert oder eine Reihe von Werten zu etwas, für das man verantwortlich ist, und nicht zu etwas, das man auf eine Param/Return-Achterbahn setzen kann. Vermeiden Sie Vanilla Getters/Setters und öffentliche Eigenschaften, und Sie werden oft feststellen, dass Sie innehalten und darüber nachdenken müssen, wie Sie Ihre Anwendung auf eine Art und Weise modellieren können, die in der Regel einfacher zu lesen, zu ändern, in großen Teilen wiederzuverwenden, zu debuggen ist und der Sie vertrauen können, ohne sie bis ins Mark zu testen. Java und C# haben OOP übertrieben und es dann aufgegeben, IMO.
1 Stimmen
In einem weiteren Artikel wird versucht, Leitlinien für die Verwendung von Gettern und Settern aufzustellen: Öffentliche oder private Mitgliedsvariablen? Das YAGNI-Prinzip leitet uns dazu an, erst dann Konstrukte hinzuzufügen, wenn wir wirklich wissen, dass wir sie brauchen werden.
0 Stimmen
Punkte 2, 3 (?), 4, 5 und 8: vorläufig ja. Die anderen: definitiv nein. Was spielt es für eine Rolle, ob Sie Python, C#, Ruby, Objective-C oder einen Esolang verwenden, wenn Ihr Code einfach, elegant und leicht wartbar/erweiterbar ist?
2 Stimmen
666 Upvotes scheinen kein Zufall zu sein
2 Stimmen
"Man kann leicht erkennen, dass Sie Python nicht benutzt haben" sollte eigentlich die Nr. 1 sein!
0 Stimmen
@Kaiserludi Könnten Sie erläutern, inwiefern das eine gute Sache ist?
0 Stimmen
@DeanJ Könnten Sie bitte die Nummer 10 erklären?
0 Stimmen
@Joshua: Das war nur ein Scherz, denn der Autor hat das eindeutig nicht ernst gemeint, als er es auf die Liste gesetzt hat.
2 Stimmen
11. T
1 Stimmen
Eine kürzlich gestellte Frage hat mich an einen weiteren Grund für Set-Methoden erinnert: die Möglichkeit, eine Änderung der Eigenschaft .