mcpField
G
gof-proxy

gof-proxy

github.com/yonatankarp開発143 回インストール23 週間前に更新
リポジトリ

gof-proxy について

同じインターフェースを保ちながら、別のオブジェクトへのアクセスを制御するプロキシパターンを解説するスキルです。仮想・リモート・保護プロキシを、DecoratorやAdapterと区別できます。

主な機能

  1. 01仮想・リモート・保護プロキシ
  2. 02高コストなオブジェクトの生成遅延
  3. 03リモートオブジェクトへの呼び出し転送
  4. 04転送前の権限チェック
  5. 05プロキシの判断指針と注意点

活用シーン

  1. 01重いリソースの生成を遅らせる
  2. 02リモートオブジェクトをローカルに表現
  3. 03メソッド呼び出し前の権限確認
  4. 04テスト用の代替オブジェクトの利用

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/yonatankarp/software-design-skills --skill gof-proxy

インストール後、Claude Code で/gof-proxyを入力して読み込まれたか確認します。

詳細

一行での概要

別のオブジェクトの代理またはプレースホルダーを提供し、アクセスを制御します。クライアントには、本物のオブジェクトと直接やり取りしていないことを意識させません。

このスキルを使う場面

  • 本物のオブジェクトの作成にコストがかかり、実際に使われるまで作成を遅らせたい場合(Virtual Proxy — 画像の読み込み、重量級リソースの遅延初期化)。
  • 本物のオブジェクトが別のプロセスや別のマシンにあり、クライアントからはローカルにあるように見せたい場合(Remote Proxy — RMI、gRPC スタブ、RPC クライアント)。
  • 本物のオブジェクトへのアクセスを、権限やレート制限に照らして確認したい場合(Protection Proxy)。
  • 本物のオブジェクトをテスト用にモックするのが難しく、代役を使うとテストが容易になる場合。

このスキルを使わない場面

  • ラップしたオブジェクトに振る舞いを追加したい場合は、Proxy ではなく gof-decorator を使います。構造は同じですが、意図が異なります。
  • インターフェースを変更したい場合は、gof-adapter を使います。
  • 単純なフィールドの遅延初期化には、多くの言語にある遅延デリゲート(Kotlin の by lazy、C# の lazy)を使えばよく、Proxy クラスは不要です。

主な内容

Proxy は、代理する本物のオブジェクトと同じインターフェースを実装します。クライアントは Proxy への参照を保持してメソッドを呼び出し、Proxy は呼び出しを本物のオブジェクトに転送するかどうか、いつ転送するかを判断します。

代表的な種類は次の 3 つです。

Virtual Proxy。 初回の使用時に本物のオブジェクトを作成します。クライアントは「低コスト」な操作(例:getId() が保存済みの ID を返す)にすぐ応答を得られます。コストの高いオブジェクトが実体化するのは、実際に getData() が呼び出されたときだけです。

Remote Proxy。 リモートオブジェクトのローカルな代役です。Proxy は引数をシリアライズしてネットワーク経由で送信し、応答をデシリアライズして返します。クライアントは、リモートオブジェクトがローカルにあるかのようにコードを書けます。(注意点:リモート呼び出しをローカル呼び出しのように見せるのは、呼び出し元がネットワーク障害、遅延、部分的な結果を意識しなくなると、アンチパターンとして知られています。「分散コンピューティングにおける 8 つの誤謬」を参照してください。)

Protection Proxy。 権限チェックを追加して、本物のオブジェクトをラップします。Proxy の各メソッドは、最初に呼び出し元の権限を確認し、その後に転送するか拒否します。

判断の目安

  • Virtual Proxy:作成コストが大きく、かつ呼び出し元の大半が実際には本物のオブジェクトを必要としない場合に有効です。それ以外の場合は、単に作成してください。
  • Remote Proxy:2026 年現在、手作業で実装することはほとんどありません。gRPC、OpenAPI、GraphQL はいずれも Proxy コードを生成します。パターンを理解することは重要ですが、手作業で実装する必要は通常ありません。
  • Protection Proxy:注意が必要です。迂回できるセキュリティラッパーは、実際には保護になりません。プロセス内の Proxy ではなく、境界(コントローラー/API 層)で権限を強制してください。

アンチパターン

  • 振る舞いを追加する Proxy — Proxy の仮面をかぶった Decorator です。
  • 振る舞いが増え続ける「Smart Proxy」— いずれ Proxy ではなくなるので、リファクタリングしてください。
  • リモート呼び出しであることを呼び出し元が知らないほど隠すこと — N+1 のネットワーク呼び出しや、本番環境での予期せぬインシデントにつながります。

関連項目

  • gof-decorator — 構造は同じですが、意図は異なります(Decorator は責務を追加し、Proxy はアクセスを制御します)。
  • gof-adapter — アクセスを制御するだけでなく、インターフェースを変更する場合に使います。
  • gof-kotlin-idioms — フィールドの Virtual Proxy には by lazy が使えます。Remote Proxy には、フレームワークが生成するスタブ(gRPC、Retrofit)が使えます。独自に実装することはまれで、通常は適切ではありません。

参考資料

  • Head First Design Patterns(第 2 版)、第 11 章(「オブジェクトアクセスの制御:Proxy パターン」) — Virtual、Remote(Java RMI 経由)、Protection Proxy の各バリエーションを含む、代表的な解説です。

コメント