Все эти типы наследуют метод WriteComponent от TStream. Прочитать объект из потока можно будет с помощью метода TStream.ReadComponent.

WriteComponent сериализует объекты в двоичном формате. Однако в отладочных целях гораздо удобнее иметь дело с текстами, которые можно читать и править в Блокноте. Для перевода двоичного формата в удобочитаемый формат существует процедура ObjectBinaryToText из модуля Classes. Она принимает два параметра, которые должны содержать, соответственно, ссылку на входной поток с двоичными данными и ссылку на выходной поток, в который будет записываться текст. Процедура записи произвольной системы объектов в текстовый файл, таким образом, будет выглядеть так: Процедура записи

procedure SaveToFile(RootObject: TComponent; const FileName: TFileName); var FileStream: TFileStream; MemStream: TMemoryStream; begin FileStream := TFileStream.Create(FileName, fmCreate); MemStream := TMemoryStream.Create; try MemStream.WriteComponent(RootObject); MemStream.Position := 0; ObjectBinaryToText(MemStream, FileStream); finally MemStream.Free; FileStream.Free; end; end;

Что получится, если применить эту процедуру для записи какого-либо объекта-наследника TComponent (например, формы приложения) в текстовый файл? Если взглянуть на то, что получилось, можно увидеть нечто знакомое – а именно то, что мы видим, когда открываем в Блокноте .dfm-файл Delphi-проекта, или, щёлкнув в дизайнере форм правой кнопкой мыши на форме, выбираем команду “View as Text”. Ничего удивительного: механизм сериализации Delphi был задуман, прежде всего, для того, чтобы запоминать раскладку и взаимные отношения визуальных компонентов в .dfm-файлах. Именно поэтому создание сложных настраиваемых компонентов – ещё одна область, в которой важно понимание сериализации.

Теперь, чтобы перевести dfm-формат в двоичный поток, годный для чтения с помощью метода ReadComponent, надо использовать процедуру ObjectTextToBinary. Прочитать объекты из текстового файла можно с помощью такой процедуры: Процедура чтения

procedure LoadFromFile(RootObject: TComponent; const FileName: TFileName); var FileStream: TFileStream; MemStream: TMemoryStream; begin FileStream := TFileStream.Create(FileName, 0); MemStream := TMemoryStream.Create; try ObjectTextToBinary(FileStream, MemStream); MemStream.Position := 0; MemStream.ReadComponent(RootObject); finally MemStream.Free; FileStream.Free; end; end;

Итак, процедуры записи и чтения произвольных систем объектов готовы, и, в общем-то, на этом месте разговор можно было бы завершить. Но дело ещё и в том, что не каждый класс-наследник TComponent будет «по умолчанию» отдавать потоку свою информацию. Чтобы добиться сохранения того, что нам нужно, класс необходимо «калибровать» с помощью доработок, о которых, собственно, и пойдёт речь ниже. Такая «калибровка» – это итеративный процесс. Поэтому важно иметь надёжный метод тестирования сериализации. Помимо традиционной отладки, таким методом могут быть модульные тесты, которое вообще очень эффективны при разработке систем классов бизнес-логики. О ставшей стандартом де-факто системе модульного тестирования DUnit можно узнать на сайте http://dunit.sf.net. Ещё раз о TComponent

Прежде чем продолжить разговор о сериализации, необходимо сообщить ещё некоторые сведения о классе TComponent. Этот класс, хотя и довольно близок в иерархии VCL к простому объекту (между ним и TObject находится лишь TPersistent), уже обладает столь большой функциональностью, что хватило бы на отдельную статью. Мы рассмотрим лишь самую важную для нас часть: то, что необходимо знать для использования механизма сериализации. ПРИМЕЧАНИЕ

Для удобства в дальнейшем мы будем называть «компонентами» любые объекты, являющиеся экземплярами TComponent или классов, наследуемых от TComponent.

Я хотел бы коснуться двух связанных с классом TComponent концепций: владения и уникальных имён. Если вам всё это уже хорошо известно, можете пропустить следующие два подраздела. Владение: свойство Owner