Orchard CMS Project のソース コードを調べていたところ、必要なパラメーターが null でないことを確認しないコンストラクターがいくつかあることに気付きました。最初、これはおかしいと思いました。「この依存関係が必要だということを考えると、実際に依存関係があるかどうかを確認したくないですか?」と自問しました。プロジェクトが Castle Windsor を IoC コンテナーとして使用していることに気づいたとき、私は後で考えました。IoC コンテナーがチェックしてくれることがわかっている場合でも、チェックする必要がありますか?
それとも、ある意味で、「この依存関係をどのように取得しているのかわかりませんが、本当に必要です!」という逆カプセル化の原則を順守しているため、ダブルチェックは適切ですか?
はい。クラスの設計は、その依存関係がどのように注入されるかにとらわれず、常にその不変条件を保護する必要があります。
Ninject と構造マップの最新バージョンは、コンストラクターに入る前にバインディング例外をスローします。したがって、コンストラクターで引数の null 例外をチェックしても、とにかく役に立ちません。
だから私はあなたのコードをきれいに保つことに投票します。
防御コードに場所がないと言っているわけではありませんが、最新の IoC を使用している場合、コンストラクター チェックは場所ではありません。
将来、誰かが厳密な型委任ポリシーを適用しない別の IoC コンテナーを選択する可能性は常にあります。IoCの変更はかなり大きなアーキテクチャの決定であり、個人的にはnullチェックを自動生成するコストはおそらくそれほど重要ではないと思います。
私には、誰かがやって来て、あなたのコードを読む必要がある可能性が高いです。通常、コードが読みやすいほど、バグが発生する可能性が低くなり、メンテナンスも迅速になります。