Что делают ссылки на методы в делегатах / событиях при сериализации / десериализации объекта? - PullRequest
2 голосов
/ 10 июля 2020

в надежде, что кто-нибудь сможет мне с этим помочь. Извините, если мой технический язык неточен, все, что я знаю об этом, - это самоучка.

Я работаю над своим собственным проектом игрового движка C#, который использует сериализацию для сохранения игры. Это решение, которым я пользуюсь уже некоторое время, и оно отлично работает. Когда я впервые реализовал эту систему, проблема заключалась в том, что некоторые интерактивные объекты вызывают произвольные методы через делегатов (анонимные функции), которые могут быть «добавлены» к объекту во время выполнения. Я был немного напуган перспективой сериализации их вместе с объектами, потому что я слышал, что на самом деле сохраняется указатель / ссылка на вызываемый метод, и не гарантируется, что это будет тот же метод десериализации, что и он. было, когда он был сериализован, так я понимаю. Хотя я не совсем уверен в том, как работают эти взаимодействия, я обошел проблему, сохранив вместо этого строку, содержащую ссылочный ключ к тому, что делал делегат, и по существу «воссоздал» метод после десериализации.

В данный момент я занимаюсь рефакторингом своего кода, чтобы взаимодействие между объектами более полно использовало события. Я нахожусь на грани добавления аналогичной системы для обработчиков событий, где, когда объект добавляет обработчик событий и становится подписчиком на данное событие, объект также сделает запись, чтобы он мог повторно подписаться с той же функциональностью на событие, когда я десериализую объект. Я почти уверен, что это сработает, но я понимаю, что много работаю над проблемой, которую я не уверен, что даже полностью понимаю, потому что я не уверен, как ссылка на обработчик событий или анонимный метод в первую очередь «хранится» внутри объекта.

Например, скажем, я решил сериализовать все свои события и делегаты вместе с остальной частью объекта, к которому они прикреплены. Теперь предположим, что обработчик событий - это метод, определенный в коде. Проблема здесь в том, что если я загрузил сериализованный объект, он запустил бы последнюю версию метода, если бы я изменил ее, так как объект был сериализован (для меня это не проблема), или что ссылка на метод теперь будет указывать к несвязанному фрагменту данных в памяти приложения (огромная проблема!).

Теперь скажите, что у меня есть два объекта, и один подписывается на событие другого с помощью своего собственного анонимного делегата / обработчика событий, «созданного» во время выполнения. Теперь предположим, что я сериализовал и десериализовал оба объекта. Поскольку оба объекта существуют, будет ли у делегата / обработчика событий правильный «экземпляр метода», который был создан в другом объекте, потому что другой объект «все еще существует»? Или он просто будет содержать ссылку на память, которая не связана с недавно десериализованным объектом (который может храниться в несвязанной области памяти с тем местом, где он был изначально)?

В принципе, я не совсем понимаю, как Программа отслеживает определения своих методов и то, что именно «сохраняется» при сериализации. Ищется ли "ссылка" по указанной c ссылке / имени метода или просто в бесконтекстном фрагменте памяти (это предположение, с которым я работал до сих пор)? На позицию в памяти, в которой хранятся методы, влияет, скажем, то, как используется память программы до создания анонимного метода (создаются ли эти ссылочные местоположения «на лету» во время выполнения)?

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

Спасибо.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...