Verwenden Sie öffentliche Finale anstatt private Getter

Ich sehe die unveränderlichsten POJOs so geschrieben:

public class MyObject {
    private final String foo;
    private final int bar;

    public MyObject(String foo, int bar) {
        this.foo = foo;
        this.bar = bar;
    }

    public String getFoo() {
        return foo;
    }

    public int getBar() {
        return bar;
    }
}

Dennoch neige ich dazu, sie so zu schreiben:

public class MyObject {
    public final String foo;
    public final int bar;

    public MyObject(String foo, int bar) {
        this.foo = foo;
        this.bar = bar;
    }
}

Beachten Sie, dass die Referenzen endgültig sind, sodass das Objekt noch unveränderlich ist. Dadurch kann ich weniger Code schreiben und kürzeren Zugriff (mit 5 Zeichen: getund ()).

Der einzige Nachteil, den ich sehen kann, ist, dass Sie die Implementierung von getFoo()Down-the-Road ändern möchten, um etwas Verrücktes zu tun, was Sie nicht können. Realistisch gesehen geschieht dies jedoch nie, weil das Objekt unveränderlich ist. Sie können dies während der Instantiierung überprüfen, unveränderliche Verteidigungskopien während der Instantiierung erstellen (siehe ImmutableListz. B. Guave ) und die foooder bar-Objekte für den getAnruf vorbereiten .

Gibt es irgendwelche Nachteile, die ich vermisse?

BEARBEITEN

Ich vermute, ein weiterer Nachteil, den ich vermisse, ist die Verwendung von Serialisierungsbibliotheken mit Reflektion über Methoden, die mit getoder beginnen is, aber das ist eine ziemlich schreckliche Praxis ...

Vier Nachteile, die ich mir vorstellen kann:

1. Wenn Sie eine schreibgeschützte und veränderbare Form derselben Entität haben möchten, besteht ein gemeinsames Muster darin, eine unveränderbare Klasse Entity zu haben, die nur Accessoren mit geschützten Membervariablen verfügbar macht, und dann eine MutableEntity zu erstellen, die sie erweitert und Setter hinzufügt. Ihre Version verhindert es.
2. Die Verwendung von Gettern und Setzern entspricht der JavaBeans-Konvention. Wenn Sie Ihre Klasse als Bean in eigenschaftsbasierten Technologien wie JSTL oder EL verwenden möchten, müssen Sie öffentliche Getter verfügbar machen.
3. Wenn Sie jemals die Implementierung ändern möchten, um die Werte abzuleiten oder in der Datenbank nachzuschlagen, müssen Sie den Clientcode umgestalten. Mit einem Accessor / Mutator-Ansatz können Sie nur die Implementierung ändern.
4. Am wenigsten verwundert: Wenn ich öffentliche Instanzvariablen sehe, suche ich sofort nach Personen, die sie möglicherweise mutieren, und befürchte, dass ich die Büchse der Pandora öffne, weil die Kapselung verloren geht. http://en.wikipedia.org/wiki/Principle_of_least_astonishment

Das heißt, Ihre Version ist definitiv prägnanter. Wenn dies eine spezialisierte Klasse wäre, die nur innerhalb eines bestimmten Pakets verwendet wird (vielleicht ist der Umfang eines Pakets hier eine gute Idee), dann könnte ich dies für einmalige Fälle in Betracht ziehen. Aber ich würde keine wichtigen APIs wie dieses verfügbar machen.

Werde auch die Getter / Setter los und es geht dir gut!

Dies ist ein sehr kontroverses Thema unter Java-Programmierern.

Wie auch immer, es gibt zwei Situationen, in denen ich öffentliche Variablen anstelle (!) Von Gettern / Setzern verwende:

1. öffentliches Finale Für mich bedeutet dies "Ich bin unveränderlich" viel besser als nur ein Getter. Die meisten IDEs geben den letzten Modifikator während der automatischen Vervollständigung mit einem 'F' an. Anders als bei Gettern / Setzern, bei denen nach dem Fehlen eines setXXX gesucht werden muss.
2. public non-final Ich liebe dies für Datenklassen. Ich mache nur alle Felder öffentlich zugänglich. Keine Getter, Setter, Konstrukteure. Nein, nichts. Weniger als ein Pojo. Für mich bedeutet dies sofort: "Schau, ich bin dumm. Ich habe Daten, das ist alles. Es ist DEINE Aufgabe, die richtigen Daten in mich zu stecken." Gson / JAXB / etc. behandeln diese Klassen ganz gut. Es ist eine Wonne zu schreiben. Es gibt keinen Zweifel an ihrem Zweck oder ihren Fähigkeiten. Und das Wichtigste: Sie wissen, dass es keine Nebenwirkungen gibt, wenn Sie eine Variable ändern. IMHO führt dies zu sehr präzisen Datenmodellen mit wenigen Mehrdeutigkeiten, wohingegen Getter und Setter dieses große Problem haben, bei dem manchmal Magie in ihnen vorkommt.

Mit den Worten des Laien:

• Sie verletzen die Kapselung , um einige Codezeilen zu sparen. Das vereitelt den Zweck von OOD.
• Der Client-Code ist fest an die Namen Ihrer Klassenmitglieder gebunden. Die Kopplung ist schlecht. Der gesamte Zweck von OOD besteht darin, eine Kopplung zu verhindern.
• Sie sind sich auch sehr sicher, dass Ihre Klasse niemals wandelbar sein muss. Dinge ändern sich. Veränderung ist das einzige, was konstant ist.

Ein möglicher Nachteil, den ich sofort sehe, ist, dass Sie an die interne Darstellung der Daten in der Klasse gebunden sind. Dies ist wahrscheinlich keine große Sache, aber wenn Sie die Setter verwenden und entscheiden, dass foo und bar von einer anderen Klasse zurückgegeben werden, die an einer anderen Stelle definiert wurde, müssen die Klassen, die MyObject verbrauchen, nicht geändert werden. Sie müssten nur MyObject berühren. Wenn Sie jedoch die nackten Werte verwenden, müssen Sie Ihr MyObject, das ich verwendet habe, überall anfassen.