11
Help us understand the problem. What are the problem?

More than 1 year has passed since last update.

posted at

updated at

マンガでわかる Proxy

BD80C244-7D68-4C25-8295-143BE1F22B5B.png

これ最後、「ただいま混み合っておりますのでもう一度おかけ直しいただくか、このまましばらくお待ち下さい」ってなるアレですね。混み合ってるっていうのは、たぶんボス戦の最中でポーズできないとかの理由でしょうけど。

インターフェースが同じ軽量なオブジェクトを挟むことで、何らかの負荷対策を行うのが Proxy パターンです。めもりーちゃんの発明した電話対応ロボは、本当に必要になるまで実体へのアクセスを行わないことで、負荷対策に役立っています。

ほかにも、データ構造にいちいち実体を生成するのではなく、軽量な Proxy を差し込んでおいて、それが遅延評価したり、同じ重量級オブジェクトを参照するようにする、といった手も考えられます。これは Proxy が Flyweight パターンの実現手段となるパターンです。

逆に、混み合うリソースへのアクセスを分散する Proxy も考えられます。単純にメモ化してキャッシュもありですね。結果さえ返せれば、Proxy の先は何でもいいのです。(GoF のみなさん「その他」でまとめてサボりたかったのかな)

Proxy は AdapterDecorator とは目的が異なり、かならずしもラップ対象に委譲するわけではない、というのがポイントです。Adapter / Decorator の目的が「本来の機能への委譲」「本来の機能の拡張」なのに対して、Proxy の目的は「対外的な結果を変えずに、いかに本来の機能をサボるか」なのです。

Decorator パターンと意味区別が難しい局面もあるので、実装に対して、明確にどちらのパターンだと言い切れないこともあります。それは裏を返せば、デザインパターンで大事なのは、形ではなく意図なんだということですね。

Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
Sign upLogin
11
Help us understand the problem. What are the problem?