引数チェックの責務を設計する

みんなのウェディングの高井です。今回のエントリも、若者との対話シリーズとなります。

あるオブジェクトが別のオブジェクトを呼び出すとき、受け渡される情報のチェックをどちらの責務で行なうかという問題があります。呼び出し側でチェックを行なうのがよいのでしょうか。それとも、呼び出され側でチェックを行なうのがよいのでしょうか。

この問題は、結局のところ設計の問題であり、ケース・バイ・ケースであるというのが正解になります。ですから、どのようにケースを見極めるのかという考え方が重要です。

信頼領域

『オブジェクトデザイン』には、この問題のヒントになるアイデアが書かれています。それが、「信頼領域」という考え方です。

信頼領域とは、システムを「信頼するコミュニケーションが発生する領域に切り分け」た領域のことです。システムは、ユーザーとユーザーインタフェースの境界、外部システムとの境界、異なるレイヤーとの境界などなど、さまざまな境界によって領域づけられています。

そして、その領域をまたぐコラボレーション（メソッドを呼び出したり、メソッドが呼び出されたりする）があります。コラボレーションは、その相手となるオブジェクトが自分の属する領域から見て信頼できる領域かそうでないかによって、分類することができます。

この分類によって、受け渡される情報をチェックする責務をどちらに持たせるかを考えることができるのです。相手のオブジェクトが信頼できるか、そうでないかによって、渡す情報のチェックをするか、しないか決めれば良いということです。

信頼できないオブジェクトを呼び出すときには、呼び出し側の方にチェックをする責務を持たせた方が自然です。というのも、呼び出され側がこちらの期待通りに振る舞うとは限らないからです。

たとえば、外部のWebサービスへのリクエストに責務をもっているオブジェクトであれば、リクエストのパラメータに問題がないかどうかをWebサービスへのリクエスト前にチェックすべきです。

また、信頼できないオブジェクトから呼び出された場合には、呼び出され側で受け渡された情報のチェックを行ない、問題のあるものであれば受け入れないようにしなくてはなりません。

同じパッケージに所属しているオブジェクト間であれば、呼び出し側で渡す値のチェックもしないでしょうし、戻ってきた値のチェックもしないでしょう。同様に、呼び出され側でも渡された値のチェックをすることはありません。

呼び出し側と呼び出され側のどちらに受け渡される情報のチェックの責務を持たせるのかは、設計上の判断になります。ただ、呼び出し側からみて相手は信頼できるのか、呼び出され側からみたらどうか、そういう視点を導入するとすんなりと決まるケースが多いように感じます。

このように信頼領域という概念は、設計上の概念として便利なものです。ケース・バイ・ケースであるところに、補助線を引くことができるようになりますので、引き出しに一ついれておきましょう。