JavaでDTOデザインパターンを実装するときにsetter/getterを付けているのって
思考停止していないでしょうか、私は疑問を感じます。

※DTO Wikipedia引用
Data Transfer Object（DTO）はデザインパターンの一種で、アプリケーションソフトウェアのサブシステム間でデータを転送するのに使う

実装としてはこんな感じ。

class Hoge
{
    private int value;
    public int getValue(){ return value; }
    public void setValue(int value){ this.value = value; }
}

目的を鑑みるとロジックを含むべきものではないものと考えます。
そうするとフィールドに対するgetter/setterがあるだけの実装になります。
カプセル化も全く機能していないので、何がしたいのかはさっぱりです。
※全体の統一性のために気持ち悪いとかそういう話は理解できます。

なのでフィールドをpublicにしてしまう実装が簡潔です。
IDEからも補完がでて便利！

class Hoge
{
    public int value;
}

んじゃ次に突っ込まれる要因として、JavaのBeanになってないやんと
言われるかもしれません。

ただし、DTOの目的を考えるとBeanになる必要は無いはず。
なんでBeanにしたいの？と考えると

「BeanUtils.copyProperties」が使えないやんけ！と言われるかも。
でもそれって、目的と手段を勘違いしていませんか？と私は思います。
DTOとしては成立しているはずなのです。

んじゃなぜ「BeanUtils.copyProperties」を使いたいの？となると思います。

ご意見ご感想などございましたらお願いいたします。