Ist es in einem anti-Muster immer verwenden Methoden erhalten und stellen eine Klasse eigene Mitgliederfelder zugreifen? [Duplikat]

Question

    

Diese Frage bereits eine Antwort hier:

    

        
•              Mit Getter innerhalb Klassenmethoden                                      5 Antworten                          
    

    

In Java-Klassen ist es gut oder schlecht Praxis als Mitglied Felder mit ihren Getter und Setter zugreifen?

z, das ist besser:

public Order {
    private Agreement agreement;

    public Agreement getAgreement() {
    return agreement;
    } 

    public void process() {
       //should I use:
       getAgreement().doSomething();
       //Or:
       agreement.doSomething();
    }
}

Generell denke ich Zugriff auf das Feld direkt durch das KISS-Prinzip am besten ist, und auch jemand kann die Methode get später mit unvorhersehbaren Ergebnissen außer Kraft setzen.

Doch meine Kollegen argumentieren, dass es besser ist, eine Abstraktionsschicht zu halten. Gibt es einen Konsens über das?

Answer 1

Das Kernproblem dabei ist, dass direkte Feld Zugang zum Abfangen von der Unterklasse außer Kraft gesetzt Methoden, AOP, dynamische Proxies und dergleichen nicht förderfähig ist. Dies kann eine gute oder eine schlechte Sache auf den Fall abhängig sein. Ich würde sagen, dass intern Getter und Setter verwendet, ist nicht ein Anti-Muster oder ein Muster. Es ist eine gute oder eine schlechte Sache abhängig von der Situation, und das Design Ihrer Klasse.

Answer 2

Ehrlich gesagt, meiner Meinung nach, es hängt davon ab, was Sie verwenden es für. Persönlich, wenn im Zweifel, lasse ich immer, dass zusätzliche Abstraktionsebene in ihm nur für den Fall muß ich es später in einer Unterklasse außer Kraft zu setzen. Viele Male habe ich von dem Schmerz der Umschreiben einer Klasse nur gespeichert, weil ich einen Getter oder Setter offen zu überschreiben.

Eine andere Sache ist, dass andere Kunden / Programmierer benötigen Ihre Klasse in einer Art und Weise zu verwenden, die Sie bisher noch nicht gedacht, zum Beispiel die Vereinbarung Klasse aus einer Datenbank ziehen. In diesem Fall, wenn sie Ihre Klasse überschreiben, Sie haben es schmerzlos gemacht für sie (oder möglicherweise eine Zukunft, die Sie) zu ändern, wie die Daten abgerufen werden.

Also, wenn Sie absolut sicher, dass es nur ein Weg, das Feld zugreifen zu können, und dass es 100% direkt, es ist wahrscheinlich am besten, das Abrufen und Ändern von Werten zu entkoppeln, so dass zu einem späteren Zeitpunkt Sie sparen sie umschreiben Not.

Answer 3

Ich denke, dass die öffentliche Schnittstelle einer Klasse Verkapselung um Zustand darstellt und als solche auch die anderen Arbeiten der Klasse profitiert von dieser Kapselung.

Wenn Sie ein Feld in einer öffentlichen get-Methode eingewickelt haben, dann gibt es einen Grund, warum Sie so getan haben. Vielleicht gibt es innerhalb Logik, die Methode lazy-Last das Feld oder einen Prüfpfad bereitzustellen. Was auch immer der Grund für die Methode, Ihre Klasse wird höchstwahrscheinlich benötigen diese Logik auch.

Answer 4

Es klingt für mich wie einige Leute als etwa Getter und Setter diese Frage interpretieren, die extern verwendet werden; meine Interpretation der Frage Pablojim der war, dass es um sie innerhalb der Klasse verwendet wird, im Gegensatz zu der Klasse ihrer Felder direkt erreichbar. (Welche sind privat.)

In diesem Licht, ich bin mit Jherico und patros; verwenden den direkten Zugriff von innerhalb der Klasse, es sei denn aus irgendeinem Grund gibt es nicht.

Answer 5

eine Abstraktionsschicht zu halten, ist eine gute Sache, in Java.

Das Problem ist, dass der gesamte Code, die Ihre Mitgliedsvariablen ohne die Klasse greift direkt auf es zu merken nicht unter der Kontrolle der Klasse ist.

So, sobald Sie sich entscheiden, Ihre Klasse in einer Art und Weise zu bearbeiten, dass ein Element, das in einer Abteilung als ein Beispiel verwendet wird, nie 0 sein sollten Sie in der Lage sein müssen, um sicherzustellen, dass dieser Wert nur in einer Art und Weise geändert wird, dass dies gewährleistet . So würden Sie einen Setter für diese Methode hinzufügen und das Mitglied zu privaten ändern. Aber jetzt müssen Sie den gesamten Code ändern, um das Element ohne Setter zugreift.
Wenn Sie wissen, dass Sie den Wert verändern sich die Klasse von außen und nur dann einen Setter bieten, wenn Sie nicht wissen, die Variable privat machen, und wenn Sie Zugang benötigen später vielleicht einen Getter oder Setter bieten.

Es wird ein Anti-Muster, wenn es bestimmte Methoden in anderen Objekten, die immer verwenden für ein Mitglied bekommen dann einige Berechnungen durchführt und verwendet dann erhalten. Dies zeigt, dass entweder das Mitglied in der anderen Klasse sein soll oder dass die Methode muss in dieser Klasse sein.

Mit einem Getter und einen Setter, ohne für jedes Mitglied bricht Verkapselung darüber nachzudenken und ist kein gutes Design Wahl. Für mor Innen lesen Sie Artikel rel="nofollow

Answer 6

Ich arbeite jetzt auf etwas, das mich für den Getter macht: Wir sind jetzt Teil unserer Eigenschaften in eine „Property Bag“, bewegen, was bedeutet, Sie können nicht nur die Variable verweisen. Also zusätzlich von den Getter zu ändern, müssen wir alle Orte ändern, die diese Variable verweisen. Es ist etwas im Auge zu behalten.

Answer 7

Es hängt davon ab, was Sie Ihre Getter und Setter für verwenden. Im Allgemeinen ich sie benutzen, wenn ich zur Vernunft Prüfdaten müssen kommen in eine Klasse oder Formatdaten ausgehen. In dieser Hinsicht verwende ich wirklich Getter und Setter als Grenzschicht zwischen dieser Klasse und anderen Klassen, die Zugriff auf ihre Daten benötigen.

Ich neige dazu, meinen internen Code so zu schreiben, dass sie weiß, wie Daten privat zu dieser Klasse zu handhaben, so dass es mit seinen eigenen Getter und Setter Zugriff ist in der Regel unnötig und unerwünscht ist.

Es hängt alles davon ab, wie Sie Ihre Getter und Setter verwenden, though.

Answer 8

Meine Faustregel ist, dass, wenn sie etwas tun komplexer als nur den Wert eingestellt oder zurückzugeben, verwenden Sie den Setter / Getter. Ansonsten ist es nicht erforderlich, da Sie Probleme durch Änderungen der Elementvariablen verursacht beheben können.

Answer 9

Sie haben Recht, dass es ärgerlich ist alles, was zusätzliche Arbeit zu tun, für jede Variable zuzuordnen. Warum erlaubt die Sprache etwas so grundlegend, dass niemand tut? Es gibt sehr zwingende Gründe für nicht direkt Attribut Zugriff erlaubt, jedoch.

Ich ziehe Eiffels Unified Access-Prinzip. Sie können nie zu einem Attribute zuweisen und Attribute und Funktionen werden auf die gleiche Art und Weise zugegriffen:

class EXAMPLE
feature
  variable: INTEGER
  variable_function: INTEGER
    do
      result := 4
    end
  variable_two: INTEGER assign variable_assign
  variable_assign (in: INTEGER)
    do
      variable_two := in
    end  
end

feature
test
local
  test: EXAMPLE
  value: INTEGER
do
  create test
  value := test.variable  -- Valid
  value := test.variable_function  -- Valid and same even though it's a function
  test.variable := value -- Invalid
  test.variable_two := value -- Valid, an explicit setter is defined
end

Answer 10

Ich denke, das ist etwas, das von Fall zu Fall geprüft werden muss. einen Getter in Ihrer Klasse Code macht es komplizierter zu machen, und wahrscheinlich macht es etwas langsamer. Aber es macht auch mehr erweiterbar und wiederverwendbar es.

Was habe ich in der Regel getan ist die Getter verwenden, wenn ich ein Grund, jemand möchte forsee kann vielleicht meinen Getter mit einem anderen außer Kraft zu setzen. etwas so einfach und simpel, wenn es, dass es nie Sinn machen würde, ich weiß nicht generell Getter verwenden.

Wenn Sie Ihren Code schreiben, um die Variablen zuzugreifen, ohne den Getter, betrachten die Getter-Funktion „endgültig“ zu machen. Auf diese Weise wird niemand versuchen, Ihren Code zu überschreiben und sich die Haare ausreißen fragen, warum es nicht funktioniert. (Beachten Sie, dass Spring und Hibernate Proxies könnte dies eine schlechte Idee machen.)

Answer 11

Damit es ein Anti-Muster sein, wäre es ausgesprochen schädlich sein muß. Ich sehe nicht, wie es möglicherweise bei der Definition von Getter und Setter Schaden sein kann. Allenfalls ist es eine Verschwendung von Zeit (und Typisierung), die es sinnlos macht, aber kein Antipattern.