2

不変オブジェクトがあり、いくつかのパラメーターを受け入れるコンストラクターでその内部変数を設定します。

質問:
不変オブジェクトのコンストラクター メソッドでコンストラクター パラメーターを VALIDATE し、ArgumentExceptions有効でない場合にスローすることに問題はありますか?

(私にとっては理にかなっていますが、より良い方法やこれに問題がある場合に備えて質問したかったのです-たとえば、検証をコンストラクターからファクトリに移動する方が良い設計である場合)

または、質問を言い換えて一般化すると、次のようになります

コンストラクター メソッドにビジネス ルールに沿ったロジックを入れても問題ありませんか? それとも、コンストラクターは常にオブジェクトの内部を設定するだけでよいのでしょうか?

ありがとう

4

5 に答える 5

5

ある意味では、コンストラクター自体で検証することは理にかなっています。なぜなら、コンストラクターのすべての使用がその単一のポイントを通過することがわかっているためです。また、コードを使用する他の開発者は、「低レベル」のために間違いを犯さないように保護されます。 "検証。

検証をコール チェーンの上位に移動すると、クラス コードはきれいなままになりますが、コードが「間違った使い方をしている」バグの可能性にさらされます。

于 2012-12-19T10:10:03.447 に答える
3

クラスは、その能力を最大限に発揮して、それが行う保証を文書化し、常に有効な状態に保つために最善を尽くすべきです。不適切な、またはオブジェクトを無効な状態にする着信呼び出しは、例外を生成する必要があります。

これはコンストラクターにも当てはまります。入力を検証しないコンストラクターは、他のユーザーがクラスの無効なインスタンスを作成できるようにします。しかし、常に検証を行うと、クラスへの参照を持っている人は誰でも、それが有効であると確信できます。

于 2013-01-10T14:58:12.163 に答える
3

コンストラクターの検証には、無効なデータの場合にわずかな問題があります。その場合はどうしますか? 「無効な」インスタンスを頻繁に作成する場合、例外をスローする必要があります。

try ... catchオブジェクトをインスタンス化するたびに取り除くには、とにかくファクトリを作成する必要があります。

ファクトリは良いアプローチだと思いますが、少し異なる方法で、ファクトリ メソッドに与えられた引数を検証してから、(有効な) インスタンスを作成します。

于 2012-12-19T10:10:40.060 に答える
1

私だったら、コンストラクターに渡す前にパラメーターを検証します。コードがどのように進化するかは決してわからないため、工場で検証を行うことで、より多くの可視性が得られ、「よりクリーン」に感じるはずです。

于 2012-12-19T10:09:24.213 に答える
0

例外を発生させる場所を選択できる場合は、覚えている可能性が高い場所に移動して、 で囲んtry..catchでください。コードベースの他のユーザーも考慮すると役立ちます。これは、多くの場合、クラスの目的と、それがどのように使用されているかによって異なります。ただし、一貫性も重要です。

どちらでも例外を発生させず、代わりValidateInstance()に不変型に対して別の関数を用意すると便利な場合があります。あなたの他の選択肢は、クラスの作成(ファクトリまたはコンストラクターを介して)またはクラスの使用についてです(通常、エラーをより早くスローできる場合は悪い考えです..しかし、時には意味があります)。

それらをコンストラクターに配置すると、後で作成することを選択した場合に、Factory メソッドにも表示されるという利点があります。

HTH

于 2012-12-19T10:16:50.797 に答える