C# - быстро склонировать несложный объект
И в сериализации когда то будет проблема обновления объекта.
Конечно будет. И её никак не решить по-нормульному, чтобы все острые углы обходить. Обычно обвешивают атрибутами и дата контрактами, которые отсутствующие поля игнорируют,или оставляют, но помечают как устаревшие и неиспользуемые, новые добавленные поля дефолтят, или что-то подобное. Сохранённые состояния нужно тоже обновлять. Или забыть про них и продолжить с новыми. Так поступают везде - настройки программы в БД, сохранения из игр, несовместимые с новыми версиями. Области разные, а подход один.
ну и еще если у тебя по условию задачи в файлике один хер каждый тип только один раз записан, то почему его свойства не прописывать в стандартном конструкторе класса?
Ты сначала объяснял по-другому, якобы тебе нужно инициировать много перосонажей одного типа.
Так и осталось - нужно инициировать много персонажей одного типа. Для этого клонирую их из списка, созданного из файлика.
В конструкторе хардкодить - это в исходниках значит. А мне нужны внешние конфигурационные файлы, чтобы легко можно было в блокнотике подправить.
Во! Назову это конфигурационными файлами. А то что-то я сущности придумываю новые, а по сути это конфиги и есть.
В Repository делаешь функцию T GetInstance() where T : Character и все чистенько без дрочки с серей и десерей.
Я может не понял, что вы сказали, но нужно не ссылку на объект из репы получить, а копию объекта - т.е. скопировать все поля. Т.е. склонировать. Это надо либо вручную писать для всех полей операции копирования, либо через сериализацию-десериализацию автоматически (ну, расставив пару-тройку атрибутов). При этом при изменении состава полей сериализацию проще поддерживать - по сути надо лишь отредактировать конструктор с параметрами. Этот конструктор со всеми параметрами - аналог копировщика из С++.
А сериализация для клонирования используется ещё и потому, что я её же использую и для сохранения состояния объектов. Если бы без этого, то можно было бы просто написать свой конструктор-копировщик. А так - немного меньше работы.
Так и осталось - нужно инициировать много персонажей одного типа. Для этого клонирую их из списка, созданного из файлика.
тогда почему в твоём файле не прописать сразу всех персонажей?
Типа
Вася - Воин - меткость 100
Петя - воин - меткость 200
Кроме персонажей, которые существуют в единственном экземпляре, есть ещё враги, которых может быть много с одними и теми же параметрами. А кроме того, надо бы подумать, как и персонажей тоже клонировать. Скажем, есть базовый типа "воин", и игрок может создать себе отряд из них, но разбросать им дополнительные характеристики к базовым. Это типичная возможность таких игр с незапамятных времён. Ну и ещё неплохо бы предусмотреть возможность клонировать любого текущего персонажа или врага - на какую-нибудь будущую игровую механику с клонированием. А если заложить возможность сериализации для сохранения состояния, то клонирование получается дополнительно почти автоматически. Нужно только добавить генерацию уникального айдишника. Мой метод клонирования так и делает.
существуют в единственном экземпляре, есть ещё враги, которых может быть много с одними и теми же параметрами
Имеется ввиду класс врагов. Скажем, есть "воин", есть "крутой воин", и у них разные базовые характеристики. Но я могу пойти ещё дальше, и добавить при создании врага из базовых характеристик небольшой разброс, чтобы клоны немного отличались. Это такая особенная игровая механика. Не так уж много где это реализовано - насколько я знаю, японцы вообще этим не заморачиваются. А у меня будет особенность. Ну и по-любому это всё надо добавлять в коллекцию уже созданных и существующих в игровом мире врагов с уникальными идентификаторами. Вот поэтому механика клонирования и нужна.
Ещё раз, если сохранение состояния через сериализацию даёт возможность сохранять весь граф объектов с уникальными параметрами, то не грех воспользоваться этим для клонирования, чтобы не писать отдельные клонирующие методы, которые будут делать то же, что и сериализатор. Мой клонирующий метод будет просто сериализовать-десериализовать любой уже существующий объект с помощью любого готового фреймворка (в данный момент это Json.NET), и добавлять уникальный айдишник.
То, что я в начале говорил, это была общая идея. По мере реализации она обрастает подробностями. Но общее описание не изменилось - клонирую из списка базовых конфигураций. Отличие от типичной БД в том, что обычно в базах данных хранят уникальные объекты, а не их классы. У меня это будет храниться в сериализованном виде в файле, т.к. сохранения состояния должны быть легко портабельными (скинул файлик на флешку, или передал по сети).
Вы когда-нибудь делали программу с сохранением состояния? Не просто конфиги или ненадолго один объект в сессии сохранить, а скажем все открытые окна, вкладки и значения в них? Или скажем открыл окно, вбил значения, закрыл, а вбитые значения не стёрлись, а запомнились, и при открытии такого окна снова, то же самое было бы на тех же местах? И чтобы можно было в любой момент засейвить состояние приложения и загрузить потом тоже в любой момент? Это сложнее, чем просто сохранять некоторые настройки в конфигах. Это надо изначально классы объектов и окон писать с возможностью сохранения состояния. Вот Студию вы закрыли, открыли, а все вкладки, инструменты и даже позиция курсора запомнились и открылись так, как были.
Хотя, пример с сохранением состояний окон наверное не очень. Лучше подходит какой-нибудь редактор - графики или там звука. Свои настройки такая программа хранит в конфигах, но весь граф объектов, представляющий картинку (включая слои, фильтры, их настройки и прочее) или звуковую композицию, должен поддерживать сохранение и загрузку состояния - т.е. быть сериализуемым.
Ну а если спроектировано всё с сохранением состояния, то клонирование через сериализацию получается почти из коробки.
ну ок, если все равно сериализация нужна, то ладно - можно так сделать.
и даже позиция курсора запомнились и открылись так, как были
-----
Угу... вот только пока Студия была в оффлайне кто шаловливыми пальчиками поковырялся в редактировавшихся файликах...
Дальше пояснять?
Тогда дефолтная позиция. Также, как и при десериализации, когда кто-то поправил руками джейсон там или исходный класс, и теперь между ними несоответствие.
Большие многомиллиардные корпорации забивают на все эти мелкие проблемы маленьких людей, и если что не соответствует, то говорят просто обновиться и забить на старьё - старые сейвы в новых обновлениях могут не работать, старые конфиги в новых версиях ПО также, и т.д. А вы тут, мелкие сошки, с доходом на всю контору как пара зарплат менеджеров ФААНГов, стараетесь все-все нюансы учесть, вплоть до "а если метеорит упадёт, тогда что? в вашем ПО есть защита от этого?". Проще надо быть. )))