プロキシパターンとデコレータパターンの違い
ProxyとDecoratorの違いは何ですか？
私が見る主な違いは、Proxyがcompositionを使用し、Decoratorがaggregationを使用すると仮定すると、複数（1つ以上）を使用することで装飾子既存のインスタンスに機能を変更/追加（装飾）できますが、プロキシにはプロキシされたクラスの内部インスタンスがありますそして、いくつかの追加機能（プロキシの動作）を追加するデリゲート。
問題は、プロキシ集約で作成されたものはプロキシであるかデコレータですか？ （GoFパターンの定義により）Proxyを集約で作成することは許可されていますか？
デコレーターパターンは、オブジェクトに動的に機能を追加することに焦点を当てていますが、プロキシパターンは、オブジェクトへのアクセスの制御に焦点を当てています。
編集：-
Proxyと実際のサブジェクトの関係は通常、コンパイル時に設定されます。Proxy何らかの方法でインスタンス化しますが、Decoratorは実行時にサブジェクトに割り当てられ、サブジェクトのインターフェイスのみを認識します。
受け入れられた答えはまったく正しくありません。本当の違いは所有権（組成と集約）ではなく、タイプ情報です。
デコレータはalwaysがデリゲートを渡しました。 プロキシmight自分で作成するか、彼might注入します。
しかし、Proxyalwaysは、（より）特定のタイプの被委任者を知っています。言い換えると、Proxyとそのデリゲートは同じ基本型を持ちますが、Proxyは何らかの派生型を指します。 A Decoratorは、独自のベースタイプを指します。したがって、違いは、被委任者のタイプに関するコンパイル時の情報にあります。
動的言語では、被委任者が注入され、偶然同じインターフェースを持つ場合、違いはありません。
あなたの質問に対する答えは「はい」です。
Decorator装飾オブジェクトの参照を取得します（通常はコンストラクターを使用）。一方、Proxy自分でそれをする。
Proxyは、ラッピングオブジェクトをまったくインスタンス化しない場合があります（オブジェクトフィールド/ゲッターが使用されていない場合、DBへの不要なアクセスを防ぐためにORMを行います）whileDecoratorは常に実際のラップされたインスタンスへのリンクを保持します。
Proxy通常、セキュリティまたはキャッシング/レイジングを追加するためにフレームワークによって使用され、フレームワークによって構築されます（通常の開発者自身によってではありません）。
Decorator通常、実際のクラスではなくインターフェースに基づいて開発者自身が古いまたはレガシークラスに新しい動作を追加するために使用されます（したがって、幅広いインターフェースインスタンスで動作します） 、Proxyは具象クラスの周りにあります）。
重要な違い：
- Proxyは同じインターフェースを提供します。 Decoratorは、強化されたインターフェースを提供します。
- DecoratorとProxyの目的は異なりますが、構造は似ています。両方とも、別のオブジェクトに間接レベルを提供する方法を説明し、実装はリクエストの転送先のオブジェクトへの参照を保持します。
- Decoratorは、1つのコンポーネントのみを持つ縮退したコンポジットと見なすことができます。ただし、デコレータは追加の責任を追加します-オブジェクトの集約を目的としていません。
- Decoratorは再帰をサポートcomposition
- Decoratorクラスは、LCD（最低クラス分母））インターフェイスとのcomposition関係を宣言します、このデータメンバーはそのコンストラクタで初期化されます。
- Proxyを使用して、遅延初期化、オブジェクトのキャッシュによるパフォーマンスの改善、およびクライアント/呼び出し元へのアクセスの制御
Sourcemaking 記事は類似点と相違点を優れた方法で引用しています。
関連するSEの質問/リンク：
プロキシとデコレータは、目的と内部実装に重点を置いている場所が異なります。プロキシは、リモートオブジェクト、クロスプロセスオブジェクト、またはクロスネットワークオブジェクトをローカルオブジェクトであるかのように使用するためのものです。デコレータは、元のインターフェイスに新しい動作を追加するためのものです。
両方のパターンの構造は似ていますが、プロキシの複雑さの大部分は、ソースオブジェクトとの適切な通信を確保することにあります。一方、デコレータは、追加された動作の実装に焦点を当てています。