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」を使いたいの?となると思います。
次回
BeanUtils.copyPropertiesを利用することは思考停止していないか?
ご意見ご感想などございましたらお願いいたします。