入ってくるデータに関して妥当性を仮定しないように言われました (ユーザー入力に関して - 私は常に検証します) が、オブジェクトメソッド間で渡されるパラメーターで同じアプローチを取る理由はありますか?
メソッド パラメーターに対してアクションを実行する場合、受信パラメーターに有効なデータが含まれていることが 99.9% 確実である場合でも、常に検証する必要がありますか?
入ってくるデータに関して妥当性を仮定しないように言われました (ユーザー入力に関して - 私は常に検証します) が、オブジェクトメソッド間で渡されるパラメーターで同じアプローチを取る理由はありますか?
メソッド パラメーターに対してアクションを実行する場合、受信パラメーターに有効なデータが含まれていることが 99.9% 確実である場合でも、常に検証する必要がありますか?
場合によります。
ライブラリのパブリック メソッド、ユーザー入力で動作するメソッドなど、入力が無効になる可能性がある場合にのみ検証する必要があります。
検証されないメソッドは、ファサード デザイン パターンまたは追加のレイヤーを使用して、ユーザーから保護する必要があります。
同じことを何度も検証すると、コードを保守するときにエラーのリスクが高まり、安全性があまり向上せず、コード ベースのサイズが大きくなります。
通常、それは私が使用する場所です
assert
選択した言語がそれを提供する場合のステートメント。利点は、パラメーターの事前/事後条件を表現することです。これらは将来の開発者向けのコメントとして機能し、通常はコンパイラー/インタープリターへのフラグによって切り替えることができるため、アサート エラーの結果としてコードが爆発することはありません。
コンピューター プログラミングでは、アサーションとはプログラム内に配置される述語 (true-false ステートメント) であり、開発者が述語がその場所で常に真であると考えていることを示します。-アサーションに関する Wiki
少なくとも、境界レイヤー (Facades など) の public メソッドからのパラメーターを検証する必要があります。それ以外の場合は、パラメーターを検証する必要があるかどうかを検討する必要があります。別のホットスポットは永続性です。永続化メソッドのパラメーターを検証することをお勧めします。