コンストラクターの複雑さ

私は、コンストラクターがどれだけの作業を行えるかについて同僚と議論しています。内部に別のオブジェクトAを必要とするクラスBがあります。オブジェクトAは、クラスBがその仕事をするために必要な数少ないメンバーの1つです。そのパブリックメソッドはすべて内部オブジェクトAに依存します。オブジェクトAに関する情報はDBに格納されているので、コンストラクターでDBを検索して検証および取得を試みます。私の同僚は、コンストラクターがコンストラクターのパラメーターをキャプチャする以外に多くの作業を行うべきではないと指摘しました。コンストラクターへの入力を使用してオブジェクトAが見つからない場合、すべてのパブリックメソッドはとにかく失敗するため、インスタンスを作成して後で失敗させるのではなく、実際にはコンストラクターで早期にスローする方がよいと主張しました。

他の人はどう思いますか？それが違いを生む場合は、C＃を使用しています。

読書オブジェクトのすべての作業をコンストラクターで行う理由はありますか？ユーザーがコンストラクタに間違った値を渡した場合、そのパブリックメソッドを使用できないため、DBにアクセスしてオブジェクトAを取得することは「オブジェクトを使用可能にするために必要な他の初期化」の一部です。

コンストラクターは、オブジェクトのフィールドをインスタンス化し、オブジェクトを使用可能にするために必要な他の初期化を行う必要があります。これは一般に、コンストラクターが小さいことを意味しますが、これがかなりの量の作業になるシナリオがあります。

あなたの質問は、2つの完全に独立した部分から構成されています。

コンストラクターから例外をスローする必要がありますか、またはメソッドを失敗させる必要がありますか？

これは明らかに、フェイルファーストの原則の適用です。コンストラクターを失敗させることは、メソッドが失敗する理由を見つけることよりもデバッグがはるかに簡単です。たとえば、コードの他の部分から既に作成されたインスタンスを取得し、メソッドを呼び出すときにエラーが発生する場合があります。オブジェクトが間違って作成されていることは明らかですか？番号。

「コールをtry / catchでラップする」問題に関しては。例外があることを意味する例外。一部のコードが例外をスローすることがわかっている場合は、try / catchでコードをラップしませんが、例外をスローできるコードを実行する前にそのコードのパラメーターを検証します。例外は、システムが無効な状態にならないようにする方法としてのみ意味されます。一部の入力パラメーターが無効な状態につながる可能性があることがわかっている場合は、それらのパラメーターが発生しないようにします。この方法では、通常はシステムの境界上にある例外を論理的に処理できる場所でtry / catchを実行するだけで済みます。

コンストラクターから「DBのようなシステムの他の部分」にアクセスできますか。

これは驚くことの原則に反すると思います。コンストラクターがDBにアクセスすることを期待する人はあまりいません。だから、それをするべきではない。

あー

コンストラクターはできる限り実行すべきではありません-コンストラクターでの例外動作が厄介であるという問題があります。適切な動作が何であるか（継承シナリオを含む）を知っているプログラマーは非常に少なく、ユーザーにすべてのインスタンス化を試行/キャッチするように強制するのは、せいぜい苦痛です。

これには、コンストラクターとコンストラクターの使用という2つの部分があります。コンストラクターでは、例外が発生したときに多くのことを実行できないため、扱いにくいです。別の型を返すことはできません。nullを返すことはできません。基本的に、例外を再スローしたり、壊れたオブジェクトを返したり（不正なコンストラクター）、（ベストケース）一部の内部パーツを正常なデフォルトに置き換えたりすることができます。インスタンス化（およびすべての派生型のインスタンス化）がスローされる可能性があるため、コンストラクターの使用は厄介です。その後、メンバー初期化子では使用できません。ロジックの例外を使用して、どこでもtry / catchによって引き起こされる可読性（および脆弱性）を超えて、「作成が成功したかどうか」を確認します。

コンストラクターが自明ではないこと、または合理的に失敗すると予想されることを行っている場合は、Create代わりに静的メソッド（非パブリックコンストラクター）を検討してください。はるかに使いやすく、デバッグが簡単で、成功した場合でも完全に構築されたインスタンスを取得できます。

コンストラクター-メソッドの複雑さのバランスは、確かに良いスタイルに関する議論の問題です。かなり頻繁に空のコンストラクターClass() {}が使用され、Init(..) {..}より複雑なことのためのメソッドが使用されます。考慮すべき引数の中には：

• クラスのシリアル化の可能性
• Initメソッドをコンストラクターから分離するとClass x = new Class(); x.Init(..);、ユニットテストで部分的に同じシーケンスを何度も繰り返す必要があります。しかし、それほど良くはありませんが、読むのには非常にクリアです。時々、私はそれらを1行のコードに入れるだけです。
• ユニットテストの目的が単なるクラス初期化テストである場合、独自のInitを持ち、中間のAssertを使用して、より複雑なアクションを1つずつ実行する方が適切です。