私にとって、防御的なプログラミングとは、自分の信念は信頼できないと信じているために、発生するとは思わない、または発生する可能性さえないと思われるケースを処理するコードを作成することを意味します。
例(コンパイルまたはテストされていない場合、利用規約が適用されます):
private String findSmallestString(Collection<String> strings) {
if (strings == null || strings.isEmpty()) return null;
Iterator<String> stringsIt = strings.iterator();
try {
String smallestString = stringsIt.next();
while (stringsIt.hasNext()) {
String candidateString = stringsIt.next();
if (candidateString == null) continue;
if (candidateString.compareTo(smallestString) < 0) {
smallestString = candidateString;
}
}
return smallestString;
}
catch (NoSuchElementException e) {
return null;
}
}
そこには、間違いなく防御機能が含まれています。
- 上部のnullまたは空のガード句。これはプライベートメソッドであるため、nullまたは空のコレクションで呼び出されないようにする必要があります。
- NoSuchElementExceptionのtry-catch; イテレータがコントラクトを実行した場合、含まれているコードがこの例外をスローしないことを証明できます。
- イテレータから出てくる文字列(最初のもの以外!)のnullityguard句。繰り返しになりますが、これはプライベートメソッドであるため、コレクションパラメーターにnullが含まれていないことを確認できるはずです(とにかくコレクションにnullを入れて何をしますか?)
ヌルチェックが防御的であることに誰もが同意するわけではありません。トライキャッチは、完全に無意味になるまでです。
私にとって、防御プログラミングの酸テストは、防御が使用されることはないと思われるということです。