Usando final público em vez de getters privados

Eu vejo os POJOs mais imutáveis ​​escritos assim:

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

No entanto, tenho a tendência de escrevê-los assim:

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

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

Observe que as referências são finais, portanto o objeto ainda é imutável. Deixa-me escrever menos código e permite mais curto (por 5 caracteres: o gete ()) acesso.

A única desvantagem que vejo é que, se você deseja alterar a implementação do getFoo()caminho para fazer algo louco, não pode. Mas realisticamente, isso nunca acontece porque o Objeto é imutável; você pode verificar durante a instanciação, criar cópias defensivas imutáveis ​​durante a instanciação (consulte Goiabas, ImmutableListpor exemplo) e preparar os objetos fooou barpara a getchamada.

Faltam algumas desvantagens?

EDITAR

Suponho que outra desvantagem que estou perdendo são as bibliotecas de serialização usando reflexão sobre os métodos que começam com getor is, mas essa é uma prática bastante terrível ...

Quatro desvantagens que consigo pensar:

1. Se você deseja ter uma forma somente leitura e mutável da mesma entidade, um padrão comum é ter uma classe imutável Entidade que exponha apenas acessadores com variáveis ​​de membro protegidas, crie uma MutableEntity que a estenda e adicione setters. Sua versão evita isso.
2. O uso de getters e setters segue a convenção JavaBeans. Se você quiser usar sua classe como um bean em tecnologias baseadas em propriedades, como JSTL ou EL, precisará expor getters públicos.
3. Se você quiser alterar a implementação para derivar os valores ou procurá-los no banco de dados, precisará refatorar o código do cliente. Uma abordagem de acessador / mutador permite alterar apenas a implementação.
4. Menos espanto - quando vejo variáveis ​​de instância pública, procuro imediatamente quem pode estar mudando e tenho medo de abrir a caixa de pandora porque o encapsulamento está perdido. http://en.wikipedia.org/wiki/Principle_of_least_astonishment

Dito isto, sua versão é definitivamente mais concisa. Se essa era uma classe especializada usada apenas dentro de um pacote específico (talvez o escopo do pacote seja uma boa idéia aqui), posso considerar isso para casos pontuais. Mas eu não exporia grandes APIs como esta.

Livre-se dos getters / setters também, e você está bem!

Este é um tópico altamente controverso entre os programadores Java.

De qualquer forma, existem duas situações em que eu uso variáveis ​​públicas em vez (!) De getters / setters:

1. final pública Para mim, isso significa "eu sou imutável" muito melhor do que apenas um espectador. A maioria dos IDEs indicará o modificador final com um 'F' durante o preenchimento automático. Ao contrário dos getters / setters, onde você deve procurar a ausência de um setXXX.
2. público não final Adoro isso para classes de dados. Acabei de expor todos os campos publicamente. Sem getters, setters, construtores. Não há nada. Menos que um pojo. Para mim, isso imediatamente indica "olha, eu sou burro. Eu guardo dados, isso é tudo. É SEU trabalho colocar os dados certos dentro de mim". Gson / JAXB / etc. lidar com essas classes muito bem. Eles são uma felicidade de escrever. Não há dúvida sobre seu objetivo ou capacidade. E o mais importante: você sabe que não há efeitos colaterais ao alterar uma variável. IMHO isso resulta em modelos de dados muito concisos, com poucas ambiguidades, enquanto getters e setters têm esse enorme problema, onde às vezes a mágica acontece dentro deles.

Nas palavras dos leigos:

• Você viola o encapsulamento para salvar algumas linhas de código. Isso derrota o propósito do OOD.
• O código do cliente será fortemente associado aos nomes dos alunos. O acoplamento está ruim. Todo o objetivo do OOD é impedir o acoplamento.
• Você também tem certeza de que sua turma nunca precisará ser mutável. As coisas mudam. Mudança é a única coisa que é constante.

Uma possível desvantagem que vejo de imediato é que você está vinculado à representação interna dos dados na classe. Isso provavelmente não é um grande negócio, mas se você usar os setters e decidir que foo e bar serão retornados de alguma outra classe definida em outro lugar, as classes que consomem MyObject não precisam mudar. Você só precisaria tocar em MyObject. No entanto, se você usar os valores nus, terá que tocar em todos os lugares que o MyObject eu usei.