Интерфейс и методы

← →
RIMMER (2003-06-07 23:54) [0]

Вот уже два года юзаю во многих прогах TxmlDocument со страницы Internet дельфийской палитры и все не могу понять: доступ к ветвям XML можно получить разными процедурами в переменную типа IXMLNode, т.е. в ИНТЕРФЕЙС. Тем не менее все мои IXMLNode влегкую выполняют свои методы, реализация коих в принципе отсутствует в определении интерфейса. Так как же это работает???

← →
Ihor Osov'yak (2003-06-08 00:26) [1]

Почитай какую-то книгу о COM.. Многое прояснится..

Не совсем точная аналогия, но в первом приближении допустимая - в случае использования функции из dll почему-то не возникает вопросов, почему нет реализации. Мы обходимся одной только декларацией - то есть именем функции и именем dll, которая ее экспортирует. Ну и конесно нужно знать параметры, чтобы компилятор мог корректно построить вызов..

Снова не совсем точная формулировка, но для начала сойдет - COM можно считать развитием этой техники..

Если в двух словах - интерфейсная переменная - это указатель на таблицу вызовов соотв. методов для некой програмной сущности, именуемой ком-обьектом. Об особенностях устройства ком-обьекта в общем случае знать не надо - такова идеология ком. Интерфейс - это декларация. Декларация таблицы вызовов методов интерфейса (что-то типа таблицы виртуальных методов , в первом приближении и параметров соотв. методов).. Согласно правил COM ком-обьект в случае, если он поддерживает соотв. интерфейс, должен сформировать соотв. таблицу, на которую уже указывает интерфейсная переменная.. Код ком-обьекта находится в ком-сервере, физически в большинстве случаев это или dll, внедренная в твой процесс, или вообще отдельный процесс.. Собственно поэтому при работе с интерфейсами нам не нужно знать их реализацию.. Как и для классической длл..

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

← →
Ihor Osov'yak (2003-06-08 00:31) [2]

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

========= cut here ==========
Итак, маленькое лирическое отступление в сторону COM

COM - это есть во первых, некий набор не нарушаемых ни при каких условиях правил, согласно которым одни программные объекты могут воспользоваться ресурсами других программных обьектов, а также средства операционной системы, которые обеспечивают это взаимодействие. Причем те объекты, которые используют ресурсы (далее клиенты), никогда не получают полного контроля над объектами, которые эти ресурсы отдают (далее - компоненты, или объекты COM)... Мало того, клиенту даже не обязательно иметь представление об общем устройстве объекта COM. Для их взаимодействия важно наличие оговоренного интерфейса взаимодействия и гарантии того, что этот интерфейс никогда не будет изменен.
Здесь под интерфейсом понимается набор определенных методов, которые должны быть реализованы объектом COM, и которые "предоставляются" клиенту. На уровне бинарного кода за интерфейсом стоит некая структура в памяти, которую реализует объект COM и которая предоставляет собой некую таблицу адресов методов обьекта COM. Когда говорят, что клиент получил интерфейс, то понимают, что ему стал известен адрес той структуры. Кроме того, клиент "знает", в каком порядке идут точки вхождения в этой таблице для соответствующих методов, так как клиент знаком с соответствующей спецификацией.

=== далее продолжение будет

← →
Ihor Osov'yak (2003-06-08 00:33) [3]

====== продолжение

Внимательный читатель задаст вопрос - а как же с разделением адресного пространства, ведь довольно часто клиент и объект COM живут в разных процессах, и следовательно их адресные пространства изолированы друг от друга? Как же тогда клиент и объект COM работают с одной таблицей?
Эту проблему решает библиотека поддержки СOM, которая внедряет в адресное пространство клиента и сервера специальные служебные объекты, называемые заместителями (для клиента) и заглушками (для сервера) (здесь под сервером понимается тот процесс, который создал один или несколько экземпляров объектов COM). Таким образом клиент будет взаимодействовать с заглушкой, а сервер с заместителем. Организация взаимодействия между заглушкой и заместителем - проблема библиотеки поддержки COM.
К счастью, вся эта алхимия в большинстве случаев не требует от программиста какого-то либо вмешательства. Я во всяком случае, встречал довольно много программистов, которые активно используют COM-технологии, но понятия не имеют о тех вещах, которых мы вскользь коснулись выше.

Подытоживая, можно сказать,что интерфейс есть спецификация, которая на на уровне бинарного кода "отражается" в таблицу вызовов в памяти.
В СОМ интерфейсы - это все. Для клиента сервер представляет собой набор интерфейсов. Клиент с сервером может взаимодействовать только посредством интерфейсов. Мало того, клиент даже может не знать о всех интерфейсах, поддерживаемых сервером.
Все интерфейсы наследуются от базового интерфейса IUnnknown . Причем, если говорят о наследовании интерфейсов, то понимают не наследование реализации (с ней мы имеем дело, когда работаем в пределах объектной модели хотя бы того же Delphi), а наследование деклараций. Под наследованием деклараций понимается то, что если некий интерфейс IB наследуется от интерфейса IA, то в соответствующей таблице вызовов для интерфейса IB сначала будут идти адреса методов, которые декларируются в IA, а затем адреса методов от IB. Причем списки формальных параметров наследуемых методов не должны быть изменены. Если вспомнить, что интерфейсы есть спецификации, то становится понятным, почему по отношению к ним может идти речь только о наследовании деклараций. Конечно, при реализации конкретного COM-обьекта можно использовать технологию наследования реализации, но это будет внутреннее дело объекта, которое никак не затрагивает клиента.

В завершение разговора об COM, я хотел бы упомянуть о некоторых методах базового интерфейса IUnnknown, так как во первых, эти методы присутствуют в любом интерфейсе (вспомним о наследовании деклараций и о том, что любой интерфейс наследуется от IUnnknown) и во вторых, на использовании этих методов строится вся идеология работы с COM.

Итак, разрешите представить - QueryInterface. С помощью этого интерфейса клиент может определить, поддерживает ли COM-обьектом какой либо другой интерфейс, который известен клиенту, и получить указатель на тот интерфейс, если он поддерживается объектом. При работе с СOM, это пожалуй самый популярный вызов. В Dеlphi он иногда вызывается явно, иногда неявно. Неявный вызов происходит при применении оператора as для интерфейсных ссылок.
Интерфейс IUnnknown также декларирует два метода интерфейса AddRef и Release, которые ответственны за подсчет использования COM-обьекта (одно из требований к COM-обьектам - они должны уметь сами себя уничтожить, если в их услугах более никто не нуждается). Вам вряд ли придется вызывать эти методы напрямую, так как Delphi генерирует их вызовы автоматически.

Сейчас, пожалуй, самое время время взглянуть на mshtml.pas - как видим он почти на 100% состоит из одних деклараций интерфейсов - ведь нам как клиенту важно знать спецификацию. И совсем не обязательно быть в курсе особенностей реализации.

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

====== конец цитаты

Интерфейс и методы Найти похожие ветки