Ist es am besten, immer Zugriffsmethoden zu verwenden, selbst wenn auf den lokalen Status zugegriffen wird?

Hängt davon ab. Für kleine schnelle Klassen, bei denen Accessoren nichts tun, würde ich sagen, die Felder direkt zu benutzen. Für größere Klassen, in denen Accessoren und Setter Nebenwirkungen haben könnten, würde ich Accessoren verwenden.

Auf der Android-Plattform scheint die Android-Dokumentation zu stimmen. Sie gehen sogar so weit, dass sie in bestimmten Fällen den Schutz auf Paketebene empfehlen. Siehe die Abschnitte mit dem Titel "Interne Getters / Setter vermeiden" und "Package Scope mit inneren Klassen verwenden" in Ссылка .

Alles hängt von der Umgebung, der Größe des Codes und davon ab, ob es aus Gründen der Codepflege "Standards" gibt. Ich weiß nur, dass es kleine Leistungsunterschiede gibt, aber letztendlich liegt es am Entwickler / Team.

Ich würde sagen, es liegt an der Diskretion des Entwicklers.

Ich bevorzuge die Getter-Methode. Und wenn Sie eine Klassenhierarchie haben, ist es gut, den internen Zustand über geschützte Getter verfügbar zu machen.

Es ist eine gute Übung, weil Sie nie sicher sein können, wie Sie sich das Alter zu einem späteren Zeitpunkt ändern möchten. Es kann eine Validierung oder etwas anderes erfordern und es ist einfacher, es in einer Methode zu ändern, als überall, wo das Feld verwendet wird (und es ist viel einfacher, einen Ort zu übersehen, an dem es verwendet wird und somit Schwierigkeiten hat, einen möglichen Fehler ausfindig zu machen ).

Wenn Ihre Klasse endgültig wäre, würde ich direkt auf die Felder zugreifen. Vertrauen Sie auf Ihre Refactoring-Fähigkeiten. Wenn du es später ändern willst, kannst du es immer tun.

Ich benutze Getter und Setter auch für einfache Klassen, da es in Ihrem Code "Hooks" erzeugt, was das Erweitern erleichtert. Wenn Sie also jedes Mal, wenn ein Benutzer eine bestimmte Objekteigenschaft ändert, einen Prüfeintrag erstellen möchten, ist dies einfach. Dann, wenn ich am Ende meines Projekts angelangt bin, nehme ich mir einen Moment Zeit und lösche die Getter und Setter, die ich nicht benutzt habe. Ich finde das effektiv, weil die meisten IDEs die Accessoren für Sie generieren, so dass nicht viel Zeit verschwendet wird ...

Ich sehe Leute, die posten, "Wenn du es später ändern willst, kannst du es immer tun." . Dies ist in großen Projekten nicht immer trivial, wenn Sie im gesamten Code direkt auf Ihre Objekteigenschaften zugreifen.

Oft gehen Leute mit this.age in einer einfachen Klasse, aber überlegen Sie sich die Vorteile von Accessoren, wenn Sie sie bereits haben. Wenn Sie zum Beispiel einen Tag einführen möchten, sagen Sie, wenn jemand älter wird, müssen Sie ihn an jedem Ort ablegen, den Sie "this.age" nennen. Oder stattdessen können Sie es einfach in den Accessor legen. Code-Stil ist nicht immer festgelegt, aber normalerweise gibt es einen guten Grund, wenn Sie danach suchen.

Ein paar Gründe, warum Accessoren "kann" eine bessere Option sein:

1. Sie verwenden ein spöttisches Framework, um Ihren Code zu testen, und möchten den von einem Getter zurückgegebenen Wert BEIDEN ändern UND bestätigen, dass er aufgerufen wurde.
2. Sie möchten die meisten (wenn nicht alle) Ihrer öffentlichen Klassen als Schnittstellen verfügbar machen (z. B. wenn Sie in der Lage sein möchten, dynamische Proxies usw. zu erstellen). Dies kann beinhalten, dass Zugriffsmethoden in der Schnittstelle verfügbar gemacht werden (der Aufrufer muss nicht wissen, dass er einfach eine lokale Eigenschaft abruft)
3. Sie entwickeln eine Bibliothek für den öffentlichen Verbrauch, und ein "einfacher Refactor" ist nicht geeignet, da er in der Anwendung des Endbenutzers zu Kompilierungsfehlern führen kann. Accessors können entsprechend veraltet sein, ohne das Verhalten der Benutzer der früheren Bibliothek zu beeinträchtigen.
4. Sie möchten sich das Recht vorbehalten, das Verhalten des Accessors zu einem späteren Zeitpunkt oder in einer abgeleiteten Klasse zu ändern, ohne es vollständig zu entfernen (siehe vorherigen Punkt).
5. Viele Abhängigkeits-Injection-Frameworks erwarten, dass ein "Bean" der JavaBeans-Spezifikation entspricht und daher über Zugriffsmechanismen für alle Eigenschaften verfügt.

IMHO: Ich folge dem You-Aint-Gonna-Need-It-Prinzip, die Dinge einfach zu halten. Viele Entwickler sind besorgt, dass Sie eines Tages vielleicht einen Getter oder Setter brauchen, wenn das tatsächlich nie passiert.

Sie sollten tun, was Sie für am klarsten halten, vor allem für diejenigen, die Ihren Code pflegen müssen.

Ich würde empfehlen, int zu verwenden, es sei denn, der Wert muss null oder ein Objekt sein. Wenn Sie einen Wert von maximal Null benötigen, sollten Sie danach suchen.

d. entweder

ODER

Hinweis

Während Accessoren Codezeilen zu Ihren Klassen hinzufügen, fügen sie wirklich Wert beim Refactoring von Code hinzu. Sie müssen eine andere Klasse benachrichtigen, dass sich eine Eigenschaft geändert hat? BAM! Es gibt ein Ereignis und triggert es innerhalb des Accessor-Codes.

Wenn Sie nur die Membervariable zugänglich machen, müssen Sie entweder den Accessor erstellen, wenn Sie das Ereignis erstellen müssen, oder daran denken, die Logik anzuhängen, um das Objekt jedes Mal zu benachrichtigen, wenn ein Objekt außerhalb Ihrer Klasse die Membervariable ändert.

Ich denke, Accessoren sind großartig für ihre Flexibilität bei Komplexitätsverhältnissen. Außerdem benötigen einige Frameworks wie Hibernate sie. Sprachen wie .net haben auch Code-Strukturen wie Attribute, die nicht auf Member-Variablen angewendet werden können (aka WCF DataMember).

hoffe das hilft!