Что такое "технология COM" и как с ней бороться?

    (один из вопросов, заданный автору рассылки на интервью для дружественной редакции)

В этой рассылке мы должны были бы рассмотреть что такое интерфейс с точки зрения его реализации в computer sciences. Сегодня в тексте должны бы были появиться пусть пока небольшие, но уже фрагменты кода. Но "в редакцию пришли письма". В них авторы называют меня разными хорошими словами (оставим это на их совести, возможно, они просто пока до конца ещё не разобрались :-) и задают несколько важных вопросов:

• Если наша рассылка - практическое введение, то на каких языках программирования будут приводиться примеры?

• Какие технические средства и инструменты будут использоваться?

• По COM/OLE существуют книжки. Что это за книжки и которые из них можно рекомендовать для самостоятельного изучения COM?

• Чем моя рассылка будет отличаться от тех самых книжек?

Поскольку сформулированные вопросы - мои упущения в изложении, то в этой рассылке я постараюсь исправиться. Так, наверное, нужно делать и дальше - как только вопросов накапливается на самостоятельный выпуск, на них нужно ответить. В общем, я предлагаю такой механизм обратной связи. Вы, безусловно, можете присылать свои вопросы и предложения мне, мой адрес - vasilisk@nm.ru Эти вопросы и предложения будут влиять на дальнейшее изложение, возможно, и не в виде конкретного ответа на конкретный вопрос - плавность повествования тоже забывать нельзя. Если же вы хотите получить конкретный ответ на конкретный вопрос, то на сайте http://about.al.ru открыт Форум, на котором вы можете его сформулировать. Форум не требует регистрации, и на нём "тусуется" целая группа программистов, не только один я. Наша "группа профессиональных программистов" будет рада, если вы к нам присоединитесь и поможете нам отвечать на вопросы, или, наоборот, их задавать.

Начнём с ответа на первый вопрос - про языки программирования. COM - двоичная технология, т.е. всё равно на каком языке написаны клиент и сервер. Но действительно существуют предпочтения в отношении языков, на которых они на самом деле пишутся. И "средневзвешенная норма" выглядит здесь следующим образом. COM-серверы, преимущественно, пишутся на языках C и C++. Дело в том, что С и C++ - пожалуй, единственные языки, которые прямо и эффективно транслируются в машинные команды. "Машинно-эффективнее", чем C/C++ может быть только Ассемблер, но на Ассемблере невозможно писать большие программы и область его применения совсем другая.

На C/C++ труднее писать программы, чем на VB или Java, но COM - технология, предназначенная для повторного использования кода, т.е. эффективность реализации сервера, пусть даже ценой бóльших затрат программиста - оправданна в полном цикле "создание - использование". Ведь "написано однажды - работает везде". А на C/C++ программист в самом буквальном смысле слова может делать всё и очень коротко. Так как основные трудности и проблемы COM находятся на стороне сервера, а не клиента, то и возможность C/C++ закодировать всё, что угодно оказывается весьма полезной. Более того, проектные абстракции C++ прямо отображаются в абстракции COM, поэтому программист может мыслить в одной системе понятий, для него конструкции COM будут просто специализациями конструкций C++. Для нас в методическом плане это обстоятельство исключительно важно - практически всю "анатомию COM" мы сможем изложить не выходя за рамки C++ и не плодя сущностей сверх меры.

Сказанное не означает невозможности реализовать COM-сервер с использованием других средств. Например, современный VB позволяет создать проект, который будет являться COM-сервером. Это можно сделать быстро и просто, собственно, ничего "от самого COM" программист и не увидит, а сервер действительно будет работать. Но … машинная эффективность такого сервера будет невелика, а размер - огромен. Поэтому для индустриального производства COM-компонент такой подход не применяется, хотя в конкретном частном стечении обстоятельств вполне может быть использован. Случай Delphi, как VB-подобного инструмента, но - с настоящей компиляцией кода, является своего рода очень приятным исключением, которое, к сожалению, только подтверждает правило.

COM-клиенты, напротив, преимущественно пишутся на VB и скриптовых языках, типа VBScript. Конструкция COM-клиента - намного проще конструкции COM-сервера и в "общую неэффективность COM" клиент вносит весьма скромный вклад. Поэтому при разработке клиента важным обычно является скорость самой разработки. Это тоже соотносится с общей идеей - повторное использование кода клиента значительно менее распространено, чем повторное использование кода сервера.

И опять - сказанное не означает, что COM-клиент невозможно написать на C++. Можно, хотя, по сравнению с написанием его на VB это - ещё то удовольствие. Но в конкретном стечении обстоятельств, когда вам, скажем, требуется какая-то предельная вычислительная эффективность клиента (сортировка, поиск и т.д.) и в нем есть один-два вызова COM-объектов, вы, конечно, закодируете эти вызовы на C++ - эффективность остальной части клиента будет важнее.

В целом же, серверы обычно пишутся на C++, а клиенты - на VB. При выборе своего проектного решения об этом стоит помнить. Поэтому для нашей рассылки рабочими языками примеров будут C/C++ и VB/VBA. Уметь на них программировать - весьма желательно; если вы хотите быть профессиональным COM-программистом - совершенно необходимо, но для понимания нашего изложения качество владения языком программирования не очень существенно.

Какие технические средства и инструменты будут использоваться? Для С++ и VB - Microsoft Visual Studio 6.0a, как самый распространенный в этом деле инструмент. Это не означает, что примеры не могут быть реализованы с использованием других компиляторов, просто готовые проекты примеров будут сделаны именно в этом средстве. Естественно, что мы будем пользоваться и утилитами, входящими в комплект поставки Visual Studio. В качестве носителя VBA мы будем использовать Microsoft Excel - тоже достаточно распространенную программу.

В отношении же среды исполнения можно сказать следующее. Технология COM (тогда ещё называвшаяся OLE) была отлажена еще в Windows 3.1. И, будучи включенной в Windows 95, уже была свободной от ошибок в достаточной степени. Все дальнейшие операционные системы с платформой Win32 имеют встроенные средства поддержки COM хорошей степени отлаженности, и, главное, спецификация COM на них - в точности одна и та же. Поэтому гарантируется, что примеры COM будут работать одинаково во всех операционных системах Microsoft, начиная от Windows 95 OSR2. Впрочем, за Windows CE я поручиться не берусь, потому, что ни разу для нее компонентов не писал. Кроме того, ошибки операционной системы в уровне поддержки COM маловероятны еще и потому, что сама операционная система - компонентное изделие. В этом можно убедиться, заглянув в системный реестр в раздел HKCR\CLSID сразу после инсталляции только системы, до инсталляции всех других программ. CLSID, экспонируемых самой системой, там более, чем достаточно.

Какие существуют книги по COM/OLE и вообще, какие могут быть ещё источники информации? Я начинал изучение OLE в далёком теперь уже 1995 году по книге "OLE за 21 день", к сожалению, не помню сейчас её автора. Других книг на русском языке в то время не было, а эта книга доставила мне в высшей степени сумбурные представления. Во всяком случае, научиться по ней написать хотя бы один, но полностью свой, работающий объект я не смог. Основным источником информации для меня выступила Сеть и собственная работа.

Сейчас положение изменилось - с тех пор выпущена не одна хорошая книга. Лучшей я считаю книгу Дейла Роджерсона "Основы COM" - более толковой книги я не видел, во всяком случае в ней я нашел ответы на очень многие вопросы, которые у меня были. Неплохой для тех, кто пишет свои программы на C++, является и книга Эндрю Трельсена "Модель COM и применение ATL 3.0". Ну а классика жанра, конечно, книга Крейга Брукшмидта Inside OLE. В английском варианте она полностью входит в MSDN.

В собственной практике важным источником информации о том, как работает COM для меня явились исходные тексты ATL 1.1 - набора темплетных классов, который тогда только-только разработала Microsoft для облегчения тяжкой жизни программиста COM. Читая Дейла Роджерсона я вручную декомпилировал темплеты и изучал как реализуются те или иные конструкции COM. Лучшего примера кода я привести не могу! Сейчас ATL существует уже в третьей версии, так что примеров продвинутого кода только добавилось.

Чем рассылка будет отличаться от книг? Я думаю, что здесь могу задать и встречный вопрос вам, мои читатели. Количество читателей нашей рассылки достигло по состоянию на момент написания этих строк 2912 человек - для рассылки которой нет ещё и месяца это очень много. Рассылка популярна... вот и вопрос - почему? Почему вы меня читаете? Чем и как моя рассылка отличается от моря информации по нашей теме, которое сейчас есть и в Сети и в книжных магазинах? Нужно ли повысить уровень изложения, понизить, или оставить как есть? Что нужно было бы рассмотреть ещё, а рассмотрение чего есть пустая трата времени? Поскольку смысл моей работы по сочинению как раз и есть вы, то информация о точной настройке на ваш интерес будет исключительно важна для меня. Напишите мне!

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

Конечно, и COM имеет такие инструменты. Самых известных два - MFC и ATL. При умелом использовании они здорово облегчают жизнь. Но мы пока не будем ими пользоваться никак. Наша ближайшая задача несколько иная - понять, как функционирует COM на уровне конструкций своей программы и вызовов операционной системы. Весь код первого, самого примитивного, примера будет написан руками на "голом C++" с одной-единственной целью - понять и откомментировать каждую деталь, которую он реализует. В дальнейшем мы двинемся в двух направлениях - мы будем усложнять наш первый примитивный пример вводя в него всё новые конструкции, соответствующие нашему продвижению вперёд, и мы будем переписывать наш пример с использованием инструментальных средств, т.е. мы будем одновременно выяснять какие конструкции COM в себе инкапсулируют стандартные средства и как именно.

Кроме того - написание программ в компонентной модели не есть просто приделывание к готовой программе дополнительного служебного кода COM и только. "Компонентность" влияет на саму архитектуру модуля. Как и в каких случаях - это тоже тема нашей рассылки.

В любом случае, я прошу не полагаться как на источник знания только на рассылку. Читайте другую литературу по COM, сопоставляйте, ищите противоречия и неясные места. Задавайте вопросы.

А "Откуда суть пошли интерфейсы программные" мы рассмотрим в следующий раз...