Спасибо за сочувствие - но я просто рассказал что ожидает на пути который Вы предложили
Это если вы его будете реализовывать... И я думаю это еще далеко не все проблемы.
Но я пожалел ваших заказчиков по другому поводу: за ваше умение набить себе цену на решение обычных технических вопросов (т.е. за свою непосредственную работу).
Давайте углубимся в детали.
- нужно хранить/отслеживать коллекции
Это бесспорно хит.
Так же, можно просить заказчика увеличить стоимость проекта на треть в связи с тем, что вам придется хранить и отслеживать все объекты системы, и самое главное не забывать их удалять при завершении ее работы.
- при де-сериализации я не могу восстановить указатель немедленно (хз текстура загружена или нет). Нужна фаза "восстановления ссылок/связок"
А нам для восстановления указателя вообще не нужны данные картинки, поэтому никаких "фаз восстановления ссылок/связей" здесь не нужно. (Заказчик бы плакал от такой красивой фразы).
Нужно разделить класс текстур и класс картинок. Объект текстуры можно создать сейчас, а данные картинки загрузить через десять с половиной секунд. Или вообще не загружать, ведь они нужны только для визуализации. К тому же текстура может иметь возможность хранить изображения разных размеров.
Поэтому, идея текстура == картинка изначально, эммм, недальновидная.
- загружая текстуру (объект на который ссылаются) я не могу от нее немедленно избавиться (напр если файл картинки отсутствует). До того как разрешены ссылки я вынужден сидеть с невалидным объектом текстуры, что довольно мерзко
Не могу ничего пояснить, потому что не могу представить что вы имеете ввиду.
- возникают трудности с сериализацией части данных. Хотя эти трудности объективны - от этого не легче
Какие трудности и почему они объективные?
В общем, типовая ситуевина когда стройная архитектура классов превращается в море латок, а умничание быстро заканчивается
А это действительно очень грустно, если у вас каждая архитектура превращается в море латок, так можно разувериться в профессии.