原文: http://www.martinfowler.com/eaaCatalog/remoteFacade.html

ネットワーク越しのレスポンスを改善するための細かい粒度のオブジェクトに対して荒い粒度のファサードを提供する

解説の全文は『PofEAA』 388 ページを参照。

オブジェクト指向モデルにおけるリモートファサードは小さなメソッドを持っている小さなオブジェクトがいっぱいある時に使うのがベストだ。これで、振る舞いを制御したり代用したり、またアプリケーションを分かりやすくするような命名規則を使う機会が多く得られる。きめ細かい動作のために、通常オブジェクト間のインタラクションが多数あると、そのようなインタラクションは通常多くのメソッド起動を必要とする、ということだ。

単一のアドレス空間内であれば、きめ細かいインタラクションはちゃんと動くが、これがプロセス間を跨いだ呼び出しを行うとそうとは限らない。リモート呼び出しは、データをマーシャリングしないといけないし、セキュリティもチェックしないといけない。パケットをスイッチ間でちゃんとルーティングしないといけないのでコストがとても高くなる。2つのプロセスがそれぞれ地球の裏側のマシンで走っているとすると、光の速度自体が要因となるかもしれないのだ。残念な真実は、どんなプロセス間呼び出しはプロセス内呼び出しよりも、かなりコストがかかる、ということだ。それはたとえ、2つのプロセスが同じマシン上で動作していても、である。このようなパフォーマンスの影響はたとえ遅延最適化の信仰者に対してであっても無視することはできないのだ。

結果、リモートオブジェクトとして使うよう意図されているオブジェクトは、何かを取得するのに必要となる呼び出し回数を最小にする粒度の荒いインタフェースが必要だ。この影響は、メソッド呼び出しだけではなく、オブジェクトにも影響がある。個々のオーダやオーダラインを求めるのではなく、1回の呼び出しでオーダやオーダラインにアクセスし、更新を実施する必要がある。これは、オブジェクトの構造全体に影響する話だ。小さなオブジェクト小さなメソッドで実現していた、明確な意図、きめ細かい制御を放棄するのだ。プログラミングは難しくなるし、生産性も低下するだろう。

リモートファサードはウェブ上のきめ細かいオブジェクトの、粒度の荒いファサード(Gang of Four)だ。細かいオブジェクトにはリモートインタフェースを持たせず、リモートファサードにもドメインロジックは含めない。リモートファサードがすることは、粗いメソッド呼び出しを細かいオブジェクトへ翻訳することだけだ。

translated by money@andore.com


PofEAA index | パターンカタログの日本語版 | パターンカタログの英日対応表