私は、NULLチェックをやりすぎを避けるためにしようとしているが、同時に、私はそれはコードを堅牢にする必要があるときにはnullチェックをしたいです。しかし、時には、私はそれがそんなに守備の私はAPIを実装していないので、になり始めるように感じます。そして、私はいくつかのヌルチェックを避けるが、私はユニットテストを開始するとき、それは常に実行時例外を待つために開始します。バランスを感じるためにどのように正しいアプローチは、どのようなものです。ここで私はこれまでに収集したノートは、次のとおりです。
- 適切なヌルチェックが行われているので、インスタンスのクラスは、各機能本の責任を負いません前とインスタンスクラスのプライベートメソッドで不要なヌルチェックを避けます
- publicメソッドにnullのチェックを行い、公共の使用のための契約に関数の動作を説明
- コンストラクタではnullチェックを行います
私は私が開始を混乱ダミー例を挙げてみましょう：
ここではインターフェースのデフォルトの機能は次のとおりです。
default void someFunction() {
// instantiaded foo and filters
foo = processFoo(foo, filters);
// do some operations with foo
// null check if processFoo's contract returns null (description in the implementation)
}
実装：
Foo processFoo(foo, filters) {
// Should I null check foo and filters?
// Operations with foo.someFields
// Operations with filters.someFields
return foo; // If I null check then I should return some exception or null to the caller function.
// If I don't null check just return received foo.
}
一般的なルールでは、私は通話の制御にいるとき、私はヌルをチェックすることはありませんが、私のコードは、他の誰かによって呼び出すことができるならば、私はチェックを強制しません、あなたはAPIの仕様の話をしているので、あなたが入力をチェックしてパラメータやスローはIllegalArgumentException。
あなたが呼び出しの合計コントロールに含まれていない場合はもちろん、このことは、時間のほとんどを必要としていない、あなたはNPEを持っているとき、基本となるバグのどこかにはありますが、しかし、あなたは間違いなくいくつかの余分な労力が必要になります。（あなたのAPIが頻繁に呼び出されますexpecially場合、あなたは/トレース悪い呼び出し元のパターンを識別するのに役立つものが必要）。
APIを設計する際、脇アーキテクチャ自体が、あなたは（また、一人ひとりのパラメータを消毒意味する）APIが公開されているexpecially場合は、メンテナンス/トラブルシューティングおよびセキュリティにも注力しなければなりません。