Урок 78 - Использование потоков данных (часть 2/3)

Пример: Создаем пустой текстовый файл на диске C: с именем "1.txt".

procedure SeadFromStream(AStream : TStream);
var
  i          : Integer;
Begin
  try
    AStream.ReadBuffer(i, sizeof(i));
  except
    on EReadError do ShowMessage('Ошибка чтения данных');
    else ShowMessage('Неизвестная ошибка ');
  end;
end;
procedure TForm1.FormCreate(Sender: TObject);
var
  F : TStream;
  i : Integer;
begin
  Try
    F := TFileStream.Create('C:\1.txt', fmOpenRead);
    SeadFromStream(F);
    F.Free;
  finally end;
end;

Под отладкой все равно вылетают исключения, но так бывает только под отладкой... Кто повнимательнее заметил заметил что открытие файла тоже в защищенной секции. Что поделаешь, отстуствие файла это тоже ошибка, но тут я ее не стал отдельно отрабатывать, так как для исследуемой функции LoadFromStream не имеет значения к какому из потоков принадлежит переданный ей объект. Уточню, что методы ReadBuffer и WriteBuffer определенны уже в TStream. Т.е. если вы вдруг захотите написать своего наследника TStream, для своего специфического источника данных, то вам не нужно будет их переопределять самому(ой). Говоря об операциях чтения и записи следует уточнить, что не все наследники TStream позволят вам писать/читать данные одновременно. Например, в ресурс нельзя ничего писать, а из файла открытого для записи бесполезно читать. Это значит что если класс имеет метод WriteToStream, то передавать ему объект класса TResourceStream будет неправильно.

Метод Seek устанавливает позицию чтения/записи в потоке, хотя он и реализован в TStream, но его ОБЯЗАНЫ перекрывать все наследники. Он существует в 2х вариациях:

function TStream.Seek(Offset: Longint; Origin: Word): Longint;
function TStream.Seek(const Offset: Int64; Origin: TSeekOrigin): Int64;

Перекрыть нужно хотя бы один. Если один из них не будет реализован, то при необходимости всегда будет вызван другой. Если не будет ни одного, то при попытке изменить позицию чтения произойдет исключение. Метод Seek позволяет производить установку позиции от начала потока (параметр Origin = soBeginning), от текущей позиции (Origin = soCurrent), или от конца(Origin = soEnd). Для получения позиции от начала хранилища удобно пользовать свойством Position. Еще один метод, который часто нужно перекрывать в наследнике это SetSize

procedure TStream.SetSize(NewSize: Longint);

Он хоть и не абстрактный но пустой. Его сделали пустым на случай если вдруг ваш поток не поддерживает операции записи (это допустимо). В этом случае, было бы нелогичным требовать от наследника TStream реализовывать возможность изменения размера его внутреннего хранилища данных, тогда как он не предусматривает такую операцию. В простых случаях линейных хранилищ Функцию GetSize можно не переопределять. Она самостоятельно использует метод Seek для получения размеров хранилища. При использовании объектов класса следует использовать публичное свойство Size.

Теперь о реализованных высокоуровневых возможностях. Копирование больших фрагментов (более 100кб)

function CopyFrom(Source: TStream; Count: Int64): Int64;

Замечательная функция, она нам позволит скопировать большой блок данных из чужого потока, начиная с текущей позиции в потоке Source, при этом начнет писать данные, начиная с текущей позиции в нашем потоке. Для копирования будет выделен внутренний буфер размером в 60 кб, позволяющий сравнительно большими блоками копировать данные, при этом не занимая надолго сам источник данных (источник может оказаться неспособным к работе с несколькими процессами). И еще если в качестве Count указать 0, то функция поймет что нужно скопировать весь поток от начала (Внимание! Не от текущей позиции) до конца. Весьма удобная функция, при перекачке данных из медленного источника в быстрый или из ReadOnly потока в поток доступный для записи. Сериализация объектов. Сериализация это перевод структур данных (в данном случае классов наследников TComponent) в бинарное представление. В таком виде данные объектов можно передать из программы или сохранить на диске. Тут же уточняю сохраняться лишь published свойства. Потому если вы хотите использовать такой механизм в своей программе, то в published секцию следует перенести все свойства определяющие состояние объекта.

  function ReadComponent(Instance: TComponent): TComponent;
  procedure WriteComponent(Instance: TComponent);

Можно записывать несколько объектов подряд, сохранять картинки, тесктовые файлы и много чего другого. Кстати, таким же образом создается любая форма, только источником для нее становиться TResourceStream. Файл DFM сохраняется в ресурс, на лету конвертируется из текстового ресурса в бинарный и становиться доступным для загрузки функцией ReadComponent. Однако перед использованием этих функций нестандартные компоненты следует зарегистрировать при помощи функции RegisterClass. (Подробный пример см. в справке по Delphi "TStream.ReadComponent Method")

Дополнительные возможности. Реализация интерфейса IStream. Связь с COM. Наверное некоторые уже заметили созвучность имени класса TStream и COM интерфейса IStream. IStream - это универсальный интерфейс приема-передачи данных в Windows. Если бы нам удалось подружить TStream и IStream, то задачу передачи данных между двумя сторонними объектами можно было бы считать решенной. Например, передать картинку из потока TFileStream в объект класса Bitmap библиотеки GDI+. Аналогичная задача стоит при обмене данными между приложением и своей собственной Dll. Как известно в Dll нельзя передавать объекты классов, а интерфейсы очень даже можно, при этом идеально сохраняется принцип инкапсуляции класса и объектный подход к разарботке приложений. Ближе к делу. Для того чтобы получить интерфейс IStream имея объект наследник TStream необходимо дополнительно воспользоваться классом TStreamAdapter, который и реализует IStream, но не сам, а с помощью класса наследника TStream. Вот его кноструктор.

constructor Create(Stream: TStream; Ownership : TStreamOwnership = soReference);

Видно, что при создании объект должен принять экземпляр класса наследника TStream, но кроме того у него есть еще такой замечательный параметр Ownership, который указывает нужно ли уничтожать сам объект потока (тот который передали ему в конструкторе Stream: TStream). Напомню, что после того как интерфейс освобождается (переменной интерфейса присваивают nil) и больше не остается ссылок на этот объект (ссылока значит то, что у этого объекта получали интерфейс), сам объект, который релизовывал интерфейс уничтожается. Уничтожается, ну и пусть, но ведь после уничтожения у нас останеться неуничтоженным сам объект потока (наследник TStream, который и реализовывал передачу данных). Уничтожить самостоятельно мы его не можем, ведь мы не знаем, когда клиент прекратит с ним работать. Вот для это и нужно в качестве Ownership передвать значение soOwned, т.е. адптер владеет экземпляром потока и удалит его, перед тем как самоуничтожиться.

Удачи!
Встретимся в следующем уроке!