Proxy(ちょうぜつ本)
元のコードを変更せずに、同じ機能呼び出しの振る舞いを拡張するためのパターン (Kindle版 p.376)
例:JobWorkerにMailerInterfaceを実装したクラスのインスタンスを注入する
RealMailer
LoggingMailerProxy
2つ注入:MailerInterface、LoggerInterface
(MailerInterfaceを実装している)LoggingMailerProxyのsendメソッドは、注入したMailerInterfaceインスタンスに委譲
RealMailerにログ出力処理を追加できたことになる(RealMailerは変えずに)
依存性注入の考え方で設計された構造は、コンフィギュレーションによる組み換えが簡単にできるので、Proxyパターンを簡単に適用できます。(Kindle版 p.380)
Proxy は Adapter や Decorator とは目的が異なり、かならずしもラップ対象に委譲するわけではない、というのがポイントです。
Adapter / Decorator の目的が「本来の機能への委譲」「本来の機能の拡張」なのに対して、
Proxy の目的は「対外的な結果を変えずに、いかに本来の機能をサボるか」なのです。
使い所
インターフェースが同じ軽量なオブジェクトを挟むことで、何らかの負荷対策を行う
データ構造にいちいち実体を生成するのではなく、軽量な Proxy を差し込んでおいて、それが遅延評価したり、同じ重量級オブジェクトを参照するようにする
混み合うリソースへのアクセスを分散する Proxy
Decorator パターンと意味区別が難しい局面もあるので、実装に対して、明確にどちらのパターンだと言い切れないこともあります。
Python文法のデコレータはProxyパターン
関数の前後に処理を追加できるため