読者です 読者をやめる 読者になる 読者になる

エンターテイメント!!

遊戯王好きのJavaエンジニアのブログ。バーニングソウルを会得する特訓中。

Dtoの悲劇

今の現場に入って3ヶ月が経過しました。
いろいろソースを見て、思うことが結構あった。

Dtoの使い方が稚拙だと感じた。
それが起因となって、ソースの引数と戻り値が変なことになっている箇所がたくさん発生している気がする。

まずは定義。
Dtoとは
、Data Transfer Objectの略。オブジェクト間のデータ受け渡しのためのデータを格納するDto
本来は、データ格納用のオブジェクトを使わずに引数で直接渡すべきだけど、引数が多すぎると順番とか覚えらんないから、それを回避するために使う。


そして、ここから話したかったこと
例を上げると以下みたいなソース
public class Sample {

    // SampleDtoより値を貰って、計算した結果を返す。
    public void getResult(SampleDto dto) {

        // 計算実行
        String result = execute(dto);

        // 値の返却
        dto.result = result;
    }
}

public class SampleDto {
    public String str;
    public String result;
}
getResult()でSampleDtoから値を貰って、計算した結果をSampleDtoに入れて、呼出し元に値を返している。
Dtoのgetter/setterについての討論は、また今度。
一番問題なのは、入出力のDtoが一緒だということ。
これのせいで、getResult()とあるのに戻り値がないという、違和感バリバリのコードができる。
また、これが起因で、結果を意図せず変えてしまう恐れがある。
Dtoの命名が入力とも出力結果とも読み取れてしまうので、Dtoを使い回して結果を上書きする恐れがある。
ユニットテストで頻発しているのではないかと内心思っているが、ユニットテストは個人で閉じているので、
どうなっているか分からない。
まだ、問題ありそうだが、思いついた&不味いと思ったのは以上。

あーしの説明が悪いせいもあるかも知れないが、なかなか現場に話しても理解して貰えない。
メソッド名が悪いみたいな話になったりしてしまう。

上記問題が発生しない技術レベルの集団であれば、入出力のDtoを同じにしてもいいかも知れないが、
そんなことできる集団がこの世にいるとは思えない。
入出力のDtoを分けることが、結構大切なんだなぁと痛感した。