意図:
このパターンの目的は、共有を使用して、内部状態の一部が共通で、状態の他の部分が異なる可能性がある多数のオブジェクトをサポートすることです。
オブジェクトは、静的フィールドを介して状態を共有できます。
flyweight パターンを使用して多数のオブジェクトの内部状態を共有することと、静的フィールドを使用することの違いは何ですか?
flyweight が Factory を介して提供するオブジェクトのプールは、flyweight の本当の意味ですか?
意図:
このパターンの目的は、共有を使用して、内部状態の一部が共通で、状態の他の部分が異なる可能性がある多数のオブジェクトをサポートすることです。
オブジェクトは、静的フィールドを介して状態を共有できます。
flyweight パターンを使用して多数のオブジェクトの内部状態を共有することと、静的フィールドを使用することの違いは何ですか?
flyweight が Factory を介して提供するオブジェクトのプールは、flyweight の本当の意味ですか?
静的フィールドを使用すると、一度に使用できるオブジェクトのインスタンスは 1 つだけです。flyweight パターンを使用すると、任意の数の異なるインスタンスを同時に使用できます (それぞれが複数回使用されます)。flyweight パターンの標準的な例は、ドキュメント内のすべての文字に対してインスタンス化されたオブジェクトが必要なテキスト エディター用です。10,000 ワードの文書の各文字に対して 1 つのオブジェクトをメモリに保持する代わりに、必要なオブジェクトは 26 個だけです (文書で小文字のみを使用すると仮定)。1 つは文字 'a'、もう 1 つは文字 'b' などです。 .、そしてそれらは、「a」オブジェクトを必要とする何らかの機能またはアクションを実行する必要があるたびに、ドキュメント全体で一時的に何度も再利用されます。
編集: 以下の最初のコメントからの質問に答える:
したがって、26 個の異なるオブジェクトが必要なためLetter
、静的またはシングルトンのクラスを作成しても機能しません。それが静的である場合、インスタンスを作成することはできません。したがって、静的な値は、それを使用したコード内のすべての場所に適している必要があります。それがシングルトンだった場合、もちろんオブジェクトは 1 つしかありません。すべてのプロパティは、使用するたびに調整 (および調整) する必要があります。アルファベットの文字にこのパターンを使用するには、文字ごとに 1 つずつ、26 の異なるクラスが必要です...
また、「変化する可能性のあるクラスの部分」とは、実際には、一部のフィールドがクラスのインスタンスごとに異なる状態を表すことを意味します。共通の部分とは、これらの共通フィールドの値が、クラスのすべてのインスタンスではなく、それらの状態値 (たとえば、すべての「a」) に一致するオブジェクトのすべての使用に対して共通であることを意味します。
ここでも、例としてテキスト エディターを使用します。「a」である文字を処理する必要があるコード内のすべての場所では、最初に、文字オブジェクトの 26 個のインスタンスを格納するデータ構造に移動し、「a」インスタンスをフェッチします。最初に変更します/ドキュメント内のこの特定の文字「a」のニーズに合わせて、さまざまなプロパティ (プロパティは「a」としての性質に関連付けられていませんが、おそらくフォント サイズ、位置、色などに関連付けられています) を変更します。
次に、オブジェクトを使用して必要なことを行い、次にコードで「a」が必要になったときに再利用するためにストレージ構造に戻します。
Flyweight パターンは、多数の非常に類似したクラスのオーバーヘッドを回避するために使用されます。プログラミングでは、データを表すために非常に多数の小さなクラス インスタンスを生成する必要があると思われる場合があります。いくつかのパラメーターを除いてインスタンスが基本的に同じであることが認識できれば、インスタンス化する必要があるさまざまなクラスの数を大幅に減らすことができる場合があります。これらの変数をクラス インスタンスの外に移動し、メソッド呼び出しの一部として渡すことができれば、それらを共有することで個別のインスタンスの数を大幅に減らすことができます。
このコンテキストでは、Flyweight が発明されたのは、C# がいくつかのパワー ポイント チャートのラフ スケッチに過ぎなかった時代にあることを心に留めておくことが重要です。そして、言語の成熟は、これらのパターンのいくつかによって暗黙のうちに知らされました。C#にはクラスメンバーが含まれています...
クラス全体を静的として宣言するよりも、いくつかの静的メンバーで非静的クラスを宣言する方が一般的です。静的フィールドの 2 つの一般的な用途は、インスタンス化されたオブジェクトの数を保持すること、またはすべてのインスタンス間で共有する必要がある値を格納することです。
MSDN のソースC# スタティック
さらに進んで、WPF テクノロジが共有リソースを普及させた結果、多くの場合、宣言型のコードのみになりました。
そのため、選択した言語が C# の場合は、その言語に既に存在する固有のプロパティに対して Flyweight パターンを検討することをお勧めします。
パターンとその実装は少し主観的ですが、スタティックを使用することは、Flyweight を達成するための最も単純な方法ではありますが、有効な方法です。
静的を使用できる場合、それは素晴らしいことです。それ以外の場合は、触れたようなことを行うことができます...フライウェイトオブジェクトを構築するファクトリは、適切な共有オブジェクトを割り当て/参照できます。