Utilizzo di getter pubblici anziché privati

Vedo la maggior parte dei POJO immutabili scritti in questo modo:

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;
    }
}

Eppure tendo a scriverli in questo modo:

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

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

Nota che i riferimenti sono definitivi, quindi l'oggetto è ancora immutabile. Mi permette di scrivere meno codice e consente un accesso più breve (di 5 caratteri: the gete ()).

L'unico svantaggio che posso vedere è se vuoi cambiare l'implementazione di getFoo()down the road per fare qualcosa di folle, non puoi. Ma realisticamente, ciò non accade mai perché l'Oggetto è immutabile; puoi verificare durante l'istanza, creare copie difensive immutabili durante l'istanza (vedi Guava's ImmutableListper esempio) e preparare gli oggetti fooo barper la getchiamata.

Ci sono degli svantaggi che mi mancano?

MODIFICARE

Suppongo che un altro svantaggio che mi manca siano le librerie di serializzazione che utilizzano la riflessione sui metodi che iniziano con geto is, ma è una pratica piuttosto terribile ...

Quattro svantaggi a cui posso pensare:

1. Se si desidera avere una forma di sola lettura e mutabile della stessa entità, un modello comune è quello di avere un'entità immutabile di classe che espone solo gli accessori con variabili membro protette, quindi creare un oggetto MutableEntity che lo estende e aggiunge setter. La tua versione lo impedisce.
2. L'uso di getter e setter aderisce alla convenzione JavaBeans. Se si desidera utilizzare la classe come bean nelle tecnologie basate sulla proprietà, come JSTL o EL, è necessario esporre i getter pubblici.
3. Se si desidera modificare l'implementazione per ricavare i valori o cercarli nel database, è necessario refactificare il codice client. Un approccio accessor / mutator consente di modificare solo l'implementazione.
4. Il minimo stupore: quando vedo variabili di istanza pubblica, cerco immediatamente chi potrebbe averlo mutato e mi preoccupo di aprire la scatola di Pandora perché si perde l'incapsulamento. http://en.wikipedia.org/wiki/Principle_of_least_astonishment

Detto questo, la tua versione è decisamente più concisa. Se questa fosse una classe specializzata che viene utilizzata solo all'interno di un pacchetto specifico (forse l'ambito del pacchetto è una buona idea qui), allora potrei considerare questo per una tantum. Ma non vorrei esporre le principali API in questo modo.

Sbarazzati anche dei getter / setter e stai bene!

Questo è un argomento molto controverso tra i programmatori Java.

Ad ogni modo, ci sono due situtation in cui uso variabili pubbliche anziché (!) Di getter / setter:

1. finale pubblico Per me questo indica "Sono immutabile" molto meglio di un semplice getter. La maggior parte degli IDE indicherà il modificatore finale con una 'F' durante il completamento automatico. A differenza dei getter / setter, dove devi cercare l'assenza di un setXXX.
2. pubblico non-finale Adoro questo per le classi di dati. Ho appena esposto tutti i campi pubblicamente. Nessun getter, setter, costruttori. No niente. Meno di un pojo. Per me questo segnala immediatamente "guarda, sono stupido. Conservo i dati, tutto qui. È TUO compito mettere i dati giusti dentro di me". GSON / JAXB / etc. gestire queste classi bene. Sono una felicità da scrivere. Non ci sono dubbi sul loro scopo o capacità. E, soprattutto: sai che non ci sono effetti collaterali quando cambi una variabile. IMHO si traduce in modelli di dati molto concisi con poche ambiguità, mentre getter e setter hanno questo enorme problema in cui a volte accade magia al loro interno.

Nelle parole di laici:

• Si viola l'incapsulamento per salvare alcune righe di codice. Ciò sconfigge lo scopo di OOD.
• Il codice del cliente sarà associato ai nomi dei membri della tua classe. L'accoppiamento è negativo. L'intero scopo di OOD è impedire l'accoppiamento.
• Sei anche molto sicuro che la tua classe non dovrà mai essere mutevole. Le cose cambiano. Il cambiamento è l'unica cosa che è costante.

Un possibile svantaggio che riesco a vedere con disinvoltura è che sei legato alla rappresentazione interna dei dati nella classe. Questo probabilmente non è un grosso problema, ma se usi i setter e decidi che foo and bar verranno restituiti da qualche altra classe definita altrove, le classi che consumano MyObject non dovrebbero cambiare. Dovresti solo toccare MyObject. Tuttavia, se usi i valori nudi, dovresti toccare ovunque il tuo MyObject che ho usato.