8

コード レビューを行っているところ、次のようなコードに気付きました。

@Entity
@Table(name = "SOME_TABLE")
public class SomeReportClass {

@Column(name = "REPORT_NUMBER", length = 6, nullable = false)
private String reportNumber;

.....
    public String getReportNumber() {
        return reportNumber;
    }

    public void setReportNumber(String reportNumber) {
        this.reportNumber = StringUtils.trimToNull(reportNumber);
    }

}

セッター内のトリミングを見るたびに、それが最も明確な解決策ではないと感じます-その問題の一般的な慣行は何ですか?

4

4 に答える 4

4

常に値をトリミングする必要があることがわかっている場合、このシナリオはコードの重複を回避します。私の意見では、これはセッターで使用することをお勧めします

于 2013-11-08T09:49:23.700 に答える
1

セッターを使用して値を透過的に設定する以外のことを行うと、懸念の分離の原則に違反します。この設計では、設定の懸念とトリミングの懸念が永遠に絡み合っています。プログラムの存続期間中、トリミングなしの設定が必要なユース ケースが 1 つもないと 100% 確信している限り、これはすべて素晴らしいことです。必要になった場合、この設計の失敗モードは非常に哀れです:set実際には「特別な」通常のメソッドがあり、別のsetWithoutTrimmingメソッドを追加することを余儀なくされます。これは、新しいプログラマーの正気の仮定とは正反対です。

より一般的な注意として、私の選択は純粋な public フィールドを使用することです (Hibernate は Spring、Jackson などと同様にそれらをサポートしています)。トリミングなど、別の問題がある場合は、必要な変換を行う静的メソッド (純粋な関数) への明示的な呼び出しを使用します。これにより、「設定した値とゲッターが異なる値を返すのはなぜですか?」などの WAT がなく、明確で明白な設計につながります。

于 2013-11-08T10:03:45.213 に答える
0

メソッドが明確に文書化されている限り、その中のロジックは問題ないと思います。

結局のところ、セッターを呼び出す前にトリミングが実行されるコード内の場所が大量に発生することは望ましくありません。

後でストリングをトリミングする必要がなくなったと判断した場合、変更を加える必要があるのは 1 つだけです。

結局のところ、カプセル化のポイントは、データとそのデータに対する動作を同じ場所に配置することです。

于 2013-11-08T09:51:33.897 に答える