design-patterns - プロキシがサブジェクト インターフェイスをプロキシ パターンで実装する理由

Question

私はプロキシ パターンを調べていて、Proxy クラスもSubjectインターフェースを実装していることに気付きました。これは具象実装またはSubjectクラスによっても実装されます。

そうする必要がある理由を誰でも提供できますか？

プロキシ クラスに関数を作成し、この関数内でサブジェクトメソッドを呼び出すこともできます。その後、クライアント コードはこのプロキシ クラス関数を呼び出すことができ、適切なメソッドを呼び出すことができます。

Answer 1

あなたが提案した方法に従っても同じ結果が得られますが、私はそれをプロキシとは呼びません。ラッパーと呼びます。クライアントは、それぞれの機能を実行するために実際にどのクラスが使用されているかを認識できない可能性があるため、インターフェイスでプロキシ設計パターンを使用することが望ましいでしょう。クライアントはインターフェイス クラスしか見ておらず、または具象クラスsubjectについては何も知りません。これは、コードの長期的なメンテナンスにとって重要です。ProxyRealSubject

もちろん、デザインパターンは「正しい」ために従うべき厳密なものではありません。これは、一般的なソフトウェア エンジニアリング シナリオのガイドラインです。したがって、最も便利な方法で実装する必要があります。

誤解を避けるために、これをプロキシ デザイン パターンのリファレンスとして使用したことを明確にします。

Answer 2

プロキシは表面上にある必要があり、必ず、要求している実際のオブジェクトのように動作します。プロキシオブジェクトを使用しているか、プロキシによって隠されている実際のオブジェクトを使用しているかを判断できないはずです。Subjectこれが、proxy がクラスを実装する理由です。

プロキシは、ユーザーに表示されてはならないロジックをカプセル化できます。たとえば、ログ、統計、リモート サーバーへの接続などです。クラスのユーザーは、バックグラウンドで何が起こっているか気にする必要はありません。

あなたが自分で書いたコードを使用するのは 1 人だけである場合は、そこで何が起こっているかを常に知っているので、このパターンに従わないことができます。

実生活の例: たとえば、インターネット接続を考えてみましょう。ユーザーはそれを機能させたいだけで、プロキシサーバーに接続することに煩わされるべきではありません。彼にとって、インターネット接続はブラックボックスです。