Flyweight パターンを使用する必要があるデータベース駆動型アプリケーションの状況の例を教えてください。
アプリケーションのある時点で flyweight パターンを使用する必要があることをどのように知ることができますか?
フライウェイトパターンを学びました。しかし、データベース駆動型のビジネス アプリケーションでそれを使用する適切な場所を理解できません。
Flyweight パターンを使用する必要があるデータベース駆動型アプリケーションの状況の例を教えてください。
アプリケーションのある時点で flyweight パターンを使用する必要があることをどのように知ることができますか?
フライウェイトパターンを学びました。しかし、データベース駆動型のビジネス アプリケーションでそれを使用する適切な場所を理解できません。
非常に特殊なデータベース アプリケーションを除いて、Flyweightはアプリケーションで使用される可能性がありますが、データベースに永続化されているエンティティを表すクラスには使用されない可能性があります。Flyweight は、必要な時間ごとに 1 つのインスタンスをインスタンス化するとパフォーマンスが低下するほど多くのクラスのインスタンス化が必要になる可能性がある場合に使用されます。その代わりに、使用ごとにデータ値を変更するだけで、はるかに少数のインスタンスをインスタンス化し、必要なインスタンスごとにそれらを再利用します。これは、たとえば、毎秒数千のそのようなクラスをインスタンス化する必要がある場合に役立ちますが、これは通常、データベースに永続化されたエンティティには当てはまりません。
特定の問題の解決策として自然に示唆される場合は、任意のパターンを適用する必要があります。特定のパターンを適用できるアプリケーション内の場所を探す必要はありません。
Flyweight の目的はメモリの問題に対処することであるため、アプリケーションのプロファイルを作成し、同一のインスタンスが大量にあると判断した後にのみ適用するのが理にかなっています。
例として、Base Class Library の色とブラシが思い浮かびます。
Flyweight の非常に重要な部分は共有実装が不変であるため、データ駆動型アプリケーションの適切な候補は、ドメイン駆動型設計が値オブジェクトと呼ぶものですが、同じ値が多数ある場合にのみ関連します。
[DBの人ではないので、これが私の最善の推測です]
flyweight パターンの本当の利点は、必要に応じてデータを再利用できることです。もう 1 つの例は、理想的には文書内の「文字」ごとにオブジェクトを持つワード プロセッシングですが、それでは大量のメモリが消費されるため、フライウェイト メモリでは必要な一意の値を 1 つだけ格納できます。
それを見る 2 番目の (そしておそらく最も簡単な) 方法は、オブジェクト プーリングのようなものです。「オブジェクトごと」のレベルではなく、「フィールドごと」のレベルでプーリングしているだけです。
実際、今考えてみると、c(++) で (比較的小さい) メモリのチャンクを使用するのと同じように、ポインター操作を行ってデータを取得する生データを保存します。