将来誰が呼び出すかわからないため
、呼び出し階層の上位領域で変数とパラメーターを「のみ」(ほとんど)制御する
か
、間違ったパラメーターに対して各クラスを個別に保存する方がよいでしょうか。
私は今、少し曖昧です。しかし、私はクラスを保護しないままにするよりも、いくつかのifを書く傾向があります。
どう思いますか?
2 に答える
パラメータのサニタイズやビジネスルールの適用について言及している場合は、エキスパートパターンの背後にある同じ概念を適用する必要があると思います。つまり、サニタイズし、それを行うために必要な情報/知識がある場所にルールを課します。
たとえば、アプリケーションのユーザーが年齢を挿入するMVCアプリケーションでは、コントローラーで年齢が正であることを確認できますが(コントローラーが持つべき常識的な知識です)、ユーザーが間にあることを確認することしかできません。このルールが指定されているモデルレイヤーのどこかにある特定の年齢。
メソッドがクラスのパブリックインターフェイス(パブリックまたは保護されている)の一部である場合、受け取っているパラメーターを信頼できないため、それらを検証する必要があります。一方、メソッドがプライベートの場合は、渡す引数を完全に制御できます。無効なデータを渡さないことが確実な場合は、それらが常に正しいと安全に想定し、それらを検証するコードを回避できます。 。
さて、あなたのシステムのパブリックインターフェースの正確な部分は、あなた以外の誰にも明らかではないかもしれません。クラスにパブリックメソッドがある場合でも、それらが宣言されているクラスは完全にカプセル化されており、他のユーザーがアクセスできない場合があります。その場合、カプセル化のレベルが役立つ可能性があります。パラメータとして渡されるものを本当に制御しているかどうかを判断してから、特定のコンテキストでデータを検証する方が安全かどうかを判断できます。しかし、パラメータとして渡されているものを見失う可能性があると信じた瞬間に、それを検証する必要があります、IMHO。