Механизм создания отчета в формате Word

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

На первый взгляд, эта проблема решается достаточно просто, по крайней мере, когда в качестве другого модуля используется динамически загружаемая библиотека(Dynamic Link Library, DLL). В этом случае оба модуля содержатся в одном и том же адресном пространстве. Казалось бы, достаточно создать в DLL объект, а его методы вызвать из основного приложения - и задача решена. Чтобы понять, что это не так, рассмотрим небольшой пример. Определим метод IsFont в приложении:

procedure IsFont(0: TObject);

begin

if 0 is TFont then

ShowMessage(`Font')

else

ShowMessage(`Not font');

end;

procedure TForm1.Button1Click(Sender: TObject);

begin

IsFont(Font);

end;

Вызовем этот метод из приложения. В качестве параметра метода IsFont используем свойство Font формы. Как и ожидалось, появиться сообщение, что объект является шрифтом.

Теперь создадим динамически загружаемую библиотеку, поместим в нее функцию IsFont и объявим ее экспортируемой:

library FontLib;

uses

SysUtils,

Dialogs,

Graphics,

Classes;

procedure IsFont(0: TObject);

begin

if 0 is TFont then

ShowMessage(`Font')

else

ShowMessage(`Not font');

end;

exports

IsFont name `IsFont';

begin

end.

Пусть функция IsFont вызывается из библиотеки при щелчке на кнопке Button2 в вызывающем приложении:

procedure IsF(0: TObject); external `FontLib.dll' name `IsFont';

procedure TForm1.Button2Click(Sender: TObject);

begin

IsF(Font);

end;

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

Вторая проблема возникает при обобщении первой проблемы. В приведенном выше примере было известно заранее, какую функцию надо вызвать и каков список ее параметров. Соответственно, в приложении перед компиляцией программистом помещается строка кода:

procedure IsF(0: TObject); external `FontLib.dll' name `IsFont';

Эта строка определяет имя функции IsFont и список ее параметров 0: TObject, поэтому программисту, использующему эту библиотеку, потребуется документация - список функций со списком их формальных параметров. Их реализация <<вручную>> с большой вероятностью приведет к ошибкам. Для исправления ошибок потребуется время, причем без всякой гарантии, что все ошибки будут обнаружены. Хотелось бы, чтобы сам модуль мог информировать среду разработки о том, какие методы ей доступны и каковы списки их формальных параметров.

Сложности работы с различными модулями этим не ограничиваются. Например, если в одном из модулей зарезервирована память для хранения данных, то в другом модуле без специальных мер нельзя ни освободить ее, ни изменить ее размер. Это связано с тем, что в каждом модуле имеется собственный менеджер памяти. Если один модуль выделяет память, то в менеджере памяти другого модуля это никак не фиксируется. Для реализации операций связанных с применением в различных модулях общих областей памяти, необходимо наличие общего менеджера памяти. Для его создания в Delphi используется модуль ShareMem.

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

Очередная проблема возникает при передаче двоичных данных от одного приложения к другому. Многие языки программирования имеют разное внутреннее представление переменных(например, строки, логические значения), и при получении данных от заранее неизвестного приложения их интерпретация подчас невозможна.

Можно выделить и другие проблемы, которые встречаются при традиционном программировании, например:

· поиск установленной копии приложения, реализующего требуемые сервисы, и корректная его инициализация;

· обеспечение корректной работы приложения-сервера одновременно с несколькими клиентами;

· управление памятью, выгрузка из памяти приложения-сервера, когда необходимость в нем отпадет и, наоборот, предотвращение несвоевременной выгрузки.

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

Базовые понятия. Интерфейс

Основным понятием, на котором основана модель СОМ, является понятие интерфейса (interface). Без четкого понимания того, что такое интерфейс, невозможно успешное программирование СОМ-объектов.

Интерфейс является контрактом между программистом и компилятором:

· программист обязуется реализовать все методы, описанные в интерфейсе, и следовать требованиям на реализацию некоторых из них;

· компилятор обязуется создать в программе внутренние структуры, позволяющие обращаться к методам этого интерфейса из любого поддерживающего те же соглашения средства программирования.

Таким образом, СОМ является языково-независимой технологией и может использоваться в качестве <<клея>>, соединяющего программы, написанные на разных языках.

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

Интерфейсы могут наследоваться. При наследовании подразумевается, что унаследованный интерфейс должен включать в себя все методы предка.

Таким образом, необходимо понять следующее.

· Интерфейс - это не класс. Класс может выступать в роли реализации интерфейса, но класс содержит код методов на конкретном языке программирования, а интерфейс - нет.

· Интерфейс строго типизирован. Как клиент, так и реализация интерфейса должны использовать именно те методы и их параметры, которые указаны в описании интерфейса.

· Интерфейс является неизменным контрактом. Не следует определять новую версию того же интерфейса с измененным набором методов(или их параметров), но с тем же идентификатором. Это гарантирует, что новые интерфейсы никогда не будут конфликтовать со старыми. Если возникает необходимость в расширении функциональности, следует определить новый интерфейс, возможно, являющийся наследником старого, и реализовать дополнительные методы в нем.

Реализация интерфейса - это непосредственно код, реализующий методы интерфейса. При этом, за несколькими исключениями, не накладывается никаких ограничений на то, каким образом будет выглядеть реализация. Физически реализация представляет собой массив указателей на методы, адрес которого и используется в клиенте для доступа к СОМ-объекту. Любая реализация интерфейса содержит метод QueryInterface, позволяющий запросить ссылку на конкретный интерфейс из числа реализуемых.

Идентификатор GUID

Теперь можно рассмотреть проблемы выбора необходимого интерфейса из того многообразия, которое представлено в иерархии интерфейсов. Имеется существенное расхождение между идентификацией класса и интерфейса. Эти различия связаны с тем, что классы используются внутри одного и того же модуля, а интерфейсы - в различных модулях. Для того чтобы создать класс с заданными свойствами, его имя просто указывается перед конструктором. Программист сам следит за тем, чтобы имена различающихся классов не совпадали, а при их совпадении - чтобы вызывался конструктор нужного класса. При работе с несколькими модулями такой подход невозможен, поскольку модули могут создаваться разными разработчиками в разное время.

Если бы интерфейсы различались только по именам, то при случайном совпадении имен(а это происходило бы довольно часто; имя обычно несет в себе смысловую нагрузку) двух интерфейсов, реализованных в разных модулях, вместо одного модуля загружался бы другой. Поэтому для идентификации интерфейса используется структура типа GUID(Globally Unique Identifier - глобально уникальный идентификатор), которая имеет размер 16 байт(128 бит). Единственный тип данных, который предопределен для интерфейса, - это GUID. Каждый СОМ-интерфейс содержит собственный идентификатор GUID. Если разработчик реализует новый интерфейс, то этот интерфейс обязательно должен иметь GUID, причем уникальность должна соблюдаться не только в рамках данного компьютера разработчика, но и для всего мира. Эта глобальная уникальность достигается путем генерации GUID как псевдослучайного числа по алгоритму, определенному консорциумом Open Systems Foundation(сейчас он носит название Open Group) и использующему некоторые специфические характеристики данного компьютера(такие, как МАС-адрес сетевого адаптера). Алгоритм гарантирует, что все сгенерированные новые значения GUID будут отличаться от полученных ранее, даже если они генерируются на разных компьютерах.

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

СОМ-сервер