問題タブ [defensive-programming]

データの永続化に Hibernate を使用する Spring Web アプリケーションの単体テストを作成しています。私はアプリケーションを開発していません。防御的プログラミングが適用されていることを確認するために、エンティティのセッターをテストする JUnit テストを作成するのが良い考えであるかどうか疑問に思います (つまり、アプリケーションがデータベースに無効なデータを挿入しようとしないことをテストします。たとえば、age が負でないことをテストします)。 ）。

一方、@Size、@NotEmpty などのアノテーションは、エンティティのフィールドで既に使用されていることがわかります。

これは私に質問をもたらします:データベースとの相互作用のためのガードを置くのに適切な場所/レイヤーは何ですか?エンティティセッターのテストを書く必要がありますか?

ベンダーは、情報を渡すために無秩序で特大のプロキシ クラスを提供することがよくあります。多くの場合、メッセージの実際の内容にたどり着くには、次のようなプロパティに降りる必要があります。

そして、この WCF のスポーン内にあるこれらすべてのクラスには、何かを保持するオブジェクトが 1 つしかないことがわかります (これにより、物事が適切に整理されているように錯覚します)。

問題は、これらのクラスのいずれかに null が含まれる可能性があり、例外が発生することです。

ここでの防御的コーディングは禁止されています。Null チェックは、深くネストされたコードにつながる可能性があります。null をチェックしてからカウント > 0 を確認する必要があるため、配列は 2 倍悪いです。

試したりキャッチしたりできますが、デバッガーにないため、本番環境でファンにヒットした場所を知るのは困難です。

どのクラスがnullであるかをTrace経由で表示できる方法はありますか?

ソフトウェアの言葉遣いのジャングルを作成せずに、この怪物のリーフ ノードを安全に逆参照する方法はありますか?

編集：上記のリンクを貼ってくれた人に感謝します！基本的に、グーグルで見つけられなかった質問です。

最近、Joshua Bloch による『Effective Java』の第 2 版を読んでいます。項目 39 で、彼は、たとえば特定のクラス Foo のコンストラクターで、これらのオブジェクトが後でクラス Foo の状態を表すために使用される場合、引数として渡される可変オブジェクトの防御コピーを作成することをお勧めします。同じコンテキストで、悪意のある操作を実行するように設計された信頼できないサブクラスのインスタンスを返す可能性があるため、非 final クラスの clone() メソッドの使用を避けるように言及しています。

これが私が明確に得ていないものです。悪意のあるサブクラスの例として、彼は「作成時に各インスタンスへの参照をプライベートな静的リストに記録し、攻撃者がこのリストにアクセスできるようにする」クラスについて言及しています。

私の疑問：

1. 彼は、この悪意のあるクラスが、カプセル化クラスのすべてのプライベート/保護/パッケージ/パブリック インスタンスの参照を実際に記録できるということですか?

2. もしそうなら、どのようにそれが可能でしょうか?. 例を教えてください。

どうも！

このコードについて同僚と議論しています。

私の見解は、コードがある場所では、x.parentNULL であってはならないということです。null の場合は重大な問題があるので、それを知りたいです。したがって、null チェックが存在してはならず、ダウンストリーム例外が発生します。

私の同僚は、これは防御的プログラミングだと言います。また、null チェックにより、コードがアプリケーションを壊さないようにします。

私の質問は、これは防御的なプログラミングですか? それとも悪い習慣ですか？

注: ポイントは誰が正しいかではありません。私はこの例から学ぼうとしています。