Пример реализации классического шаблона Flyweight из книги GoF хранит код символа только для разделяемых «символов» и использует «GlyphContext» для хранения внешнего состояния в древовидной структуре. В этом примере также упоминаются строки и столбцы, однако в нем не упоминается, как хранить «коллекцию» маховиков (объекты «персонажей»).
Понятно, что этот шаблон позволяет избежать создания огромного количества объектов путем совместного использования экземпляров, но как можно создать структуру таких объектов (например, для представления документа), не создавая структуру ссылок на кэшированные объекты (которые сделает недействительным назначение шаблона)? Я вижу, что в других примерах кэшированные экземпляры используются в качестве «одноразовых» объектов без создания какой-либо структуры, но это, похоже, не имеет никакого смысла, поскольку его можно заменить набором статических операций.
Правильно ли сделать вывод, что если нужно ссылаться на маховики после их создания, выгода шаблона может быть грубо рассчитана как [размер внутреннего состояния] / [размер ссылки на объект], Это означает, что вес в полете только с одним полем не имеет смысла?
РЕДАКТИРОВАТЬ: я был не прав в моих "вычислениях памяти" ... Без маховиков вам все равно нужно хранить ссылки, но с маховиками вам больше не нужно хранить объекты. Основная идея вопроса все еще кажется верной - степень экономии, обеспечиваемая шаблоном, пропорциональна размеру внутреннего состояния, а не количеству «логических объектов». Правда или ложь?