Класс с атрибутом сериализации
Класс, объекты которого предполагается сериализовать стандартным образом, должен при объявлении сопровождаться атрибутом [Serializable]. Стандартная сериализация предполагает два способа сохранения объекта: в виде бинарного потока символов и в виде xml-документа. В бинарном потоке сохраняются все поля объекта, как открытые, так и закрытые. Процессом этим можно управлять, помечая некоторые поля класса атрибутом [NonSerialized] - эти поля сохраняться не будут:
[Serializable]public class Test{ public string name; [NonSerialazed] int id; int age; //другие поля и методы класса}В класс Test встроен стандартный механизм сериализации его объектов. При сериализации поля name и age будут сохраняться, поле id - нет.
Для запуска механизма необходимо создать объект, называемый форматером и выполняющий сериализацию и десериализацию данных с подходящим их форматированием. Библиотека FCL предоставляет два класса форматеров. Бинарный форматер, направляющий данные в бинарный поток, принадлежит классу BinaryFormatter. Этот класс находится в пространстве имен библиотеки FCL:
Давайте разберемся, как устроен этот класс. Он является наследником двух интерфейсов: IFormatter и IRemotingFormatter. Интерфейс IFormatter имеет два открытых метода: Serialize и Deserialize, позволяющих сохранять и восстанавливать всю совокупность связанных объектов с заданным объектом в качестве корня. Интерфейс IRemotingFormatter имеет те же открытые методы: Serialize и Deserialize, позволяющие выполнять глубокую сериализацию, но в режиме удаленного вызова. Поскольку сигнатуры одноименных методов интерфейсов отличаются, то конфликта имен при наследовании не происходит - в классе BinaryFormatter методы Serialize и Deserialize перегружены. Для удаленного вызова задается дополнительный параметр, что и позволяет различать, локально или удаленно выполняются процессы обмена данными.
В пространстве имен библиотеки FCL:
System.Runtime.Serialization.Formatters.Soapнаходится класс SoapFormatter. Он является наследником тех же интерфейсов IFormatter и IRemotingFormatter и реализует их методы Serialize и Deserialize, позволяющие выполнять глубокую сериализацию и десериализацию при сохранении данных в формате xml. Помимо методов класса SoapFormatter, xml-сериализацию можно выполнять средствами другого класса -- XmlSerializer.
Из новых средств, еще не рассматривавшихся в наших лекциях, для организации сериализации понадобятся файлы. Пространство имен IO библиотеки FCL предоставляет классы, поддерживающие ввод-вывод данных. В частности, в этом пространстве есть абстрактный класс Stream для работы с потоками данных. С одним из его потомков - классом FileStream - мы и будем работать в нашем примере.
В качестве примера промоделируем сказку Пушкина "О рыбаке и рыбке". Как вы помните, жадная старуха богатела, богатела, но после очередного желания оказалась у разбитого корыта, вернувшись в начальное состояние. Сериализация позволит нам запомнить начальное состояние, меняющееся по мере выполнения рыбкой первых пожеланий рыбака и его старухи. Десериализация вернет все в начальное состояние. Опишу класс, задающий героев пушкинской сказки:
[Serializable]public class Personage{ public Personage(string name, int age) { this.name = name; this.age = age; } //поля класса static int wishes; public string name, status, wealth; int age; public Personage couple; //методы класса}Герои сказки - объекты этого класса обладают свойствами, задающими имя, возраст, статус, имущество и супруга. Имя и возраст задаются в конструкторе класса, а остальные свойства задаются в следующем методе:
Предусловие метода предполагает, что метод вызывается один раз главным героем (рыбаком). В методе устанавливаются взаимные ссылки между героями сказки, их начальное состояние. Завершается метод сохранением состояния объектов, выполняемого при вызове метода SaveState:
void SaveState(){ BinaryFormatter bf = new BinaryFormatter(); FileStream fs = new FileStream ("State.bin",FileMode.Create, FileAccess.Write); bf.Serialize(fs,this); fs.Close();}Здесь и выполняется сериализация графа объектов. Как видите, все просто. Вначале создается форматер - объект bf класса BinaryFormatter. Затем определяется файл, в котором будет сохраняться состояние объектов, - объект fs класса FileStream. Заметьте, в конструкторе файла, кроме имени файла, указываются его характеристики: статус, режим доступа. На деталях введения файлов я останавливаться не буду. Теперь, когда основные объекты определены, остается вызвать метод Serialize объекта bf, которому в качестве аргументов передается объект fs и текущий объект, представляющий корневой объект графа объектов, которые подлежат сериализации. Глубокая сериализация, реализуемая в данном случае, не потребовала от нас никаких усилий.
Нам понадобится еще метод, описывающий жизнь героев сказки:
public Personage AskGoldFish(){ Personage fisher = this; if (fisher.name == "рыбак") { wishes++; switch (wishes) { case 1: ChangeStateOne();break; case 2: ChangeStateTwo();break; case 3: ChangeStateThree();break; default: BackState(ref fisher);break; } } return(fisher);}//AskGoldFishМетод реализует анализ желаний героини сказки. Первые три желания исполняются, и состояние героев меняется:
void ChangeStateOne(){ this.status = "муж дворянки"; this.couple.status = "дворянка"; this.couple.wealth = "имение";}void ChangeStateTwo(){ this.status = "муж боярыни"; this.couple.status = "боярыня"; this.couple.wealth = "много поместий";}void ChangeStateThree(){ this.status = "муж государыни"; this.couple.status = "государыня"; this.couple.wealth = "страна";}Начиная с четвертого желания, все возвращается в начальное состояние - выполняется десериализация графа объектов:
void BackState(ref Personage fisher){ BinaryFormatter bf = new BinaryFormatter(); FileStream fs = new FileStream ("State.bin",FileMode.Open, FileAccess.Read); fisher = (Personage)bf.Deserialize(fs); fs.Close();}Обратите внимание, что у метода есть аргумент, передаваемый по ссылке. Этот аргумент получает значение - ссылается на объект, создаваемый методом Deserialize. Без аргумента метода не обойтись, поскольку возвращаемый методом объект нельзя присвоить текущему объекту this. Важно также отметить, что метод Deserialize восстанавливает весь граф объектов, возвращая в качестве результата корень графа.
В классе определен еще один метод, сообщающий о текущем состоянии объектов:
public void About(){ Console.WriteLine("имя = {0}, возраст = {1},"+ "статус = {2}, состояние ={3}",name,age,status, wealth); Console.WriteLine("имя = {0}, возраст = {1}," + "статус = {2}, состояние ={3}", this.couple.name, this.couple.age,this.couple.status, this.couple.wealth);}Для завершения сказки нам нужно в клиентском классе создать ее героев:
public void TestGoldFish(){ Personage fisher = new Personage("рыбак", 70); Personage wife = new Personage("старуха", 70); fisher.marry(wife); Console.WriteLine("До золотой рыбки"); fisher.About(); fisher = fisher.AskGoldFish(); Console.WriteLine("Первое желание"); fisher.About(); fisher = fisher.AskGoldFish(); Console.WriteLine("Второе желание"); fisher.About(); fisher = fisher.AskGoldFish(); Console.WriteLine("Третье желание"); fisher.About(); fisher = fisher.AskGoldFish(); Console.WriteLine("Еще хочу"); fisher.About(); fisher = fisher.AskGoldFish(); Console.WriteLine("Хочу, но уже поздно"); fisher.About();}На рис. 19.6 показаны результаты исполнения сказки.
Рис. 19.6. Сказка о рыбаке и рыбке
Что изменится, если перейти к сохранению данных в xml-формате? немногое. Нужно лишь заменить объявление форматера:
void SaveStateXML(){ SoapFormatter sf = new SoapFormatter(); FileStream fs = new FileStream ("State.xml",FileMode.Create, FileAccess.Write); sf.Serialize(fs,this); fs.Close(); }void BackStateXML(ref Personage fisher){ SoapFormatter sf = new SoapFormatter(); FileStream fs = new FileStream("State.xml",FileMode.Open, FileAccess.Read); fisher = (Personage)sf.Deserialize(fs); fs.Close();}Клиент, работающий с объектами класса, этих изменений и не почувствует. Результаты вычислений останутся теми же, что и в предыдущем случае. Правда, файл, сохраняющий данные, теперь выглядит совсем по-другому. Это обычный xml-документ, который мог быть создан в любом из приложений. Вот как выглядит этот документ, открытый в браузере Internet Explorer.
Рис. 19.7. XML-документ, сохраняющий состояние объектов
19. Лекция: Интерфейсы. Множественное наследование
19.7 
Интерфейс ISerializable
При необходимости можно самому управлять процессом сериализации. В этом случае наш класс должен быть наследником интерфейса ISerializable. Класс, наследующий этот интерфейс, должен реализовать единственный метод этого интерфейса GetObjectData и добавить защищенный конструктор. Схема сериализации и десериализации остается и в этом случае той же самой. Можно использовать как бинарный форматер, так и soap-форматер. Но теперь метод Serialize использует не стандартную реализацию, а вызывает метод GetObjectData, управляющий записью данных. Метод Deserialize, в свою очередь, вызывает защищенный конструктор, создающий объект и заполняющий его поля сохраненными значениями.
Конечно, возможность управлять сохранением и восстановлением данных дает большую гибкость и позволяет, в конечном счете, уменьшить размер файла, хранящего данные, что может быть крайне важно, особенно если речь идет об обмене данными с удаленным приложением. Если речь идет о поверхностной сериализации, то атрибут NonSerialized, которым можно помечать поля, не требующие сериализации, как правило, достаточен для управления эффективным сохранением данных. Так что управлять имеет смысл только глубокой сериализацией, когда сохраняется и восстанавливается граф объектов. Но, как уже говорилось, это может быть довольно сложным занятием, что будет видно и для нашего простого примера с рыбаком и рыбкой.
Рассмотрим, как устроен метод GetObjectData, управляющий сохранением данных. У этого метода два аргумента:
GetObjectData(SerializedInfo info, StreamingContext context)Поскольку самому вызывать этот метод не приходится - он вызывается автоматически методом Serialize, то можно не особенно задумываться о том, как создавать аргументы метода. Более важно понимать, как их следует использовать. Чаще всего используется только аргумент info и его метод AddValue (key, field). Данные сохраняются вместе с ключом, используемым позже при чтении данных. Аргумент key, который может быть произвольной строкой, задает ключ, а аргумент field - поле объекта. Например, для сохранения полей name и age можно задать следующие операторы:
info.AddValue("name",name); info.AddValue("age", age);Поскольку имена полей уникальны, то их разумно использовать в качестве ключей.
Если поле son класса Father является объектом класса Child и этот класс сериализуем, то для сохранения объекта son следует вызвать метод:
son.GetObjectData(info, context)Если не возникает циклов, причиной которых являются взаимные ссылки, то особых сложностей с сериализацией и десериализацией не возникает. Взаимные ссылки осложняют картину и требуют индивидуального подхода к решению. На последующем примере мы покажем, как можно справиться с этой проблемой в конкретном случае.
Перейдем теперь к рассмотрению специального конструктора класса. Он может быть объявлен с атрибутом доступа private, но лучше, как и во многих других случаях, применять атрибут protected, что позволит использовать этот конструктор потомками класса, осуществляющими собственную сериализацию. У конструктора те же аргументы, что и у метода GetObjectData. Опять-таки, в основном используется аргумент info и его метод GetValue(key, type), который выполняет операцию, обратную к операции метода AddValue. По ключу key находится хранимое значение, а аргумент type позволяет привести его к нужному типу. У метода GetValue имеется множество типизированных версий, позволяющих не задавать тип. Так что восстановление полей name и age можно выполнить следующими операторами:
name = info.GetString("name"); age = info.GetInt32("age");Восстановление поля son, являющегося ссылочным типом, выполняется вызовом его специального конструктора:
son = new Child(info, context);А теперь вернемся к нашему примеру со стариком, старухой и золотой рыбкой. Заменим стандартную сериализацию собственной. Для этого, оставив атрибут сериализации у класса Personage, сделаем класс наследником интерфейса ISerializable:
[Serializable] public class Personage :ISerializable {...}Добавим в наш класс специальный метод, вызываемый при сериализации - метод сохранения данных:
//Специальный метод сериализацииpublic void GetObjectData(SerializationInfo info, StreamingContext context) { info.AddValue("name",name); info.AddValue("age", age); info.AddValue("status",status); info.AddValue("wealth", wealth); info.AddValue("couplename",couple.name); info.AddValue("coupleage", couple.age); info.AddValue("couplestatus",couple.status); info.AddValue("couplewealth", couple.wealth); }В трех первых строках сохраняются значимые поля объекта и тут все ясно. Но вот запомнить поле, хранящее объект couple класса Personage, напрямую не удается. Попытка рекурсивного вызова
couple.GetObjectData(info,context);привела бы к зацикливанию, если бы раньше из-за повторяющегося ключа не возникала исключительная ситуация в момент записи поля name объекта couple. Поэтому приходится явно сохранять поля этого объекта уже с другими ключами. Понятно, что с ростом сложности структуры графа объектов задача существенно осложняется.
Добавим в наш класс специальный конструктор, вызываемый при десериализации - конструктор восстановления состояния:
//Специальный конструктор сериализацииprotected Personage(SerializationInfo info, StreamingContext context) { name = info.GetString("name"); age = info.GetInt32("age"); status = info.GetString("status"); wealth = info.GetString("wealth"); couple = new Personage(info.GetString("couplename"), info.GetInt32("coupleage")); couple.status = info.GetString("couplestatus"); couple.wealth = info.GetString("couplewealth"); this.couple = couple; couple.couple = this; }Опять первые строки восстановления значимых полей объекта прозрачно ясны. А с полем couple приходится повозиться. Вначале создается новый объект обычным конструктором, аргументы которого читаются из сохраняемой памяти. Затем восстанавливаются значения других полей этого объекта, а затем уже происходит взаимное связывание двух объектов.
Кроме введения конструктора класса и метода GetObjectData, никаких других изменений в проекте не понадобилось - ни в методах класса, ни на стороне клиента. Внешне проект работал совершенно идентично ситуации, когда не вводилось наследование интерфейса сериализации. Но с внутренних позиций изменения произошли: методы форматеров Serialize и Deserialize в процессе своей работы теперь вызывали созданный нами метод и конструктор класса. Небольшие изменения произошли и в файлах, хранящих данные.
Мораль: должны быть веские основания для отказа от стандартно реализованной сериализации. Повторюсь, такими основаниями можгут служить необходимость в уменьшении объема файла, хранящего данные, и в сокращении времени передачи данных.
Когда в нашем примере вводилось собственное управление сериализацией, то не ставилась цель минимизации объема хранимых данных, в обоих случаях сохранялись одни и те же данные. Тем не менее представляет интерес взглянуть на таблицу, хранящую объемы создаваемых файлов.
| Таблица 19.1. Размеры файлов при различных случаях сериализации | ||
| Формат | Сериализация | Размер файла |
| Бинарный поток | Стандартная | 355 байтов |
| Бинарный поток | Управляемая | 355 байтов |
| XML-документ | Стандартная | 1, 14 Кб. |
| XML-документ | Управляемая | 974 байта |
Преимуществами XML-документа являются его читабельность и хорошо развитые средства разбора, но зато бинарное представление выигрывает в объеме и скорости передачи тех же данных.
20. Лекция: Функциональный тип в C#. Делегаты
20.1
Новое слово для старого понятия. Функциональный тип. Функции высших порядков. Вычисление интеграла и сортировка. Два способа взаимодействия частей при построении сложных систем. Функции обратного вызова. Наследование и функциональные типы. Сравнение двух подходов. Класс Delegate. Методы и свойства класса. Операции над делегатами. Комбинирование делегатов. Список вызовов.
