GoF book の Classic Flyweight パターンの実装例では、共有可能な「Characters」に文字コードのみを格納し、「GlyphContext」を使用して外部状態をツリー構造に格納します。この例では、行と列についても言及していますが、フライウェイト (「文字」オブジェクト) の「コレクション」を格納する方法については言及していません。
このパターンにより、インスタンスを共有することで膨大な数のオブジェクトを作成することを回避できることは明らかですが、キャッシュされたオブジェクトへの参照の構造を作成せずに (たとえば、ドキュメントを表すために) そのようなオブジェクトの構造を作成するにはどうすればよいでしょうか (これにより、オブジェクトが無効になります)。パターンの目的)？他の例では、キャッシュされたインスタンスを「使い捨て」オブジェクトとして使用し、構造を構築することはありませんが、一連の静的操作に置き換えることができるため、これは意味がないようです。
作成後に flyweight を参照する必要がある場合、パターンの利点は[固有状態のサイズ]/[オブジェクト参照のサイズ]として大まかに計算できると結論付けるのは正しいですか。これは、フィールドが 1 つしかないフライ級は意味がないということですか?
編集：「メモリ計算」が間違っていました...フライウェイトがなければ、とにかく参照を保存する必要がありますが、フライウェイトを使用すると、オブジェクトを保存する必要がなくなります。質問の基本的なポイントはまだ有効であるようです-パターンによって提供される節約の程度は、「論理オブジェクト」の数ではなく、固有の状態のサイズに比例します。正しいか間違っているか？