FlyweightとSingletonパターンの実用的な違いは何ですか？

Question

2つのパターンは同じことを実現するようです。現実世界でのさまざまなユースケースは何ですか？ ありがとう

Answer 1

シングルトンはしばしば変更可能です。それはフライ級では不可能です。例えば。フライウェイトが色を表している可能性があります。赤い色を作成した場合は混乱し、下のフライウェイトオブジェクトはコードのどこか他の場所に緑色に変更されたため、代わりに緑色になります。

また、私はシングルトンがフライウェイトのサブパターンのようなものだと言います。個々のカラーオブジェクトはシングルトンであると考えることができますが、それらはすべて、ファクトリを使用して正しいシングルトン/フライウェイトオブジェクトを選択するシステムの一部です。

妊娠については本当にたくさんあります。フライウェイトは、シングルトンが存在する間は、ユニークなオブジェクトであるかのようにAPIのユーザーに提示されません。ココア（のObjective-C）から

例：

UIApplication.sharedApplication.statusBarHidden = YES 

これは明らかに、単一のオブジェクトであり、あなたがその状態を変更することができます。

UIColor *red = [UIColor redColor] 

ユーザーは、不変であるため、赤がシングルトンであるかどうかを知る必要はありません。カラーオブジェクトを作成した後は変更できません。だから、彼らがシングルトンであろうと、新しいオブジェクトを作成するのかにかかわらず、ユーザには実質的な違いはありません。したがって、これをフライウェイトと呼ぶのがより理にかなっています。それはすべての意図についてです。

Answer 2

フライウェイトは、多くの異なる種類があるときは一つのものです。

シングルトンは1つのことがあるときです。

たとえば、Flyweight Patternを使用してキーボード文字を表すことができます。 aの1つのオブジェクト、bの1つなどです。両方とも文字ですが、異なる種類の文字です。

対照的に、シングルトンを使用してキーボードを表す場合があります。 1つしか存在できません。

Answer 3

彼らは無関係です：

フライ級ではなく、CPUとメモリを節約同じ「値」、とクラスの新しいインスタンスを作成するよりも、クラスの（明らかに不変）のインスタンス可能な限りを再利用しています。

シングルトンは、（通常は変更可能な）クラスのインスタンスが1つしかない場合です。マルチスレッド環境では、単一のインスタンスを使用してすべてのスレッドを容易にし、同じ状態を「見る」ためによく使用されます。

Answer 4

フライウェイトは、オブジェクトの内在および外因性状態の明確な分離が存在する場合に使用されます。固有の状態は、他の外部オブジェクトにわたって共有することができます。例えば、文書のヘッダーは、オブジェクトの固有状態として分類され、全体にわたって共有することができる。ただし、文書内の残りのデータは、非常に動的であり、ユーザー（外的データ）によって埋められることがあります。固有のデータを表現するために、フライウェイトオブジェクトを作成してフライウェイト工場内で管理することができます。フライウェイト・ファクトリー・オブジェクトは、フライウェイト（ヘッダー・オブジェクト）のコレクションとして機能し、このケースでは、文書のさまざまなインスタンスにわたってより早期に取り込まれ、共有されます。

Answer 5

シングルトンは構造パターンであり、フライウェイトは構造パターンであることを忘れないでください。したがって、2つのパターンの目標は完全に異なっています。

Answer 6

これらは完全に異なる2つのパターン「パターンタイプ」です。シングルトンは「創造」パターンです。作成パターンは、より一般的な「オブジェクト作成」方法論です。一方、フライウェイトは「構造パターン」です。構造パターンは、「オブジェクト作成」ではなく、インタフェースと実装でより多くのことを行う必要があります。違いを説明するもうひとつの簡単な方法は、最初のパターンタイプ "Creation patterns"がより名詞ベースであることです。 2番目の「構造パターン」タイプは、より動詞ベースです。