Дизайн кэша: мухи объектов изменяемых объектов на основе неизменяемого ключа

Question

Много разных экранов в моем приложении снова и снова ссылаются на одни и те же объекты/бизнес-объекты.
В настоящее время каждый экран ссылается на свою собственную копию каждого объекта.
Кроме того, объекты-объекты сами могут открыть доступ к другим объектам-сущностям, снова создаются новые копии объектов.
Я пытаюсь найти решение для кеширования.

Я ищу что-то похожее на boost :: flyweight.
Однако, основываясь на неизменяемом ключе/изменяемом значении и подсчете ссылок.

boost::flyweight<key_value<long, SomeObject>, tag<SomeObject> > object; 

Выше почти идеально. Я ищу аналогичный контейнер, который даст изменчивый доступ к SomeObject

Редактировать: Мне нравится синтаксис и семантика мухи. Тем не менее, мухи только позволяют const SomeObject & доступ, нет возможности изменить объект.

Edit2: Код должен составить на MSVC++ 6

Любые идеи?

Answer 1

До тех пор, пока вы счастливы, влияя на внутреннее состояние, то из внутренних элементов в boost/flyweight/key_value.hpp похоже, что вы можете уйти с const_cast. Если у вас есть свой собственный экстрактор ключей, вы должны убедиться, что он не меняется в зависимости от того, какие операции будут выполняться с помощью x mutable.

flyweight<key_value<long, SomeObject> > kvfw(2); 
SomeObject &x = const_cast<SomeObject &>(static_cast<const SomeObject&>(kvfw)); 

Answer 2

Я думаю, что если вы сделаете мухоловки изменчивыми, тогда их нельзя назвать законными мухами. Представьте себе ситуацию, когда глифы представлены как мухи. Что произойдет, если одна функция изменит кодовую точку глифа, которая представляет букву «А»? Другая функция, которая отображает глифы на экране, попытается нарисовать «A», и пользователь может увидеть «B» или что-то еще! Я думаю, вам нужны неизменные ключи, относящиеся к изменяемым объектам. Затем подумайте об использовании hash table в сочетании с некоторым механизмом подсчета ссылок.