Что такое «технология COM» и как с ней бороться?№2
СОМ - возможности велики…
Надеюсь,
что в прошлый
раз, хорошо ли, плохо ли, но ответ на
вопрос «в чём суть COM-технологии» был
сформулирован. Сегодня мы рассмотрим
некоторые хорошие детали COM подробнее. Итак,
в прошлый раз утверждалось - COM-объект, это
объект, который доступен так же, как и «локальный»
объект данного проекта, хотя, фактически, он
не располагается в данном проекте, а есть
уже готовый двоичный исполняемый ресурс. И
в предыдущей же статье утверждалось, что он
может располагаться где угодно. Там же
говорилось, что это - некая DLL. Суровая
правда состоит в том, что объект COM может
располагаться действительно где угодно. И
DLL - не единственная форма его существования.
COM-объект может жить и внутри EXE-модуля,
который может исполняться независимо (параллельно!)
от модуля, который использует этот объект, и
даже - этот самый модуль может исполняться
совсем на другом компьютере! Вы где-нибудь
видели подобное? И зачем это нужно?
Начнем
с ответа на второй вопрос. Зачем это нужно и,
если нужно, насколько это важно?
Представьте себе ситуацию - у вас есть
хороший, славный, удачный алгоритм. Скажем,
сортировка или «вычисление средней
температуры по больничной палате». Вообще
говоря, этот алгоритм появился не как
самостоятельная сущность, а в процессе
разработки какой-то большой программы
мониторинга этой средней температуры.
Заказ был именно на неё, и работать эта
программа должна была на компьютере
дежурной медсестры. Только вот в процессе
работы над этой программой выяснилось, что
существует и значительно реже используемая
и совсем не первоочередная задача подсчёта
всевозможнейшей статистики, которая, может
быть, будет отдана вам на реализацию
позднее. А может быть - и не будет отдана. Во
всяком случае, такую возможность вы видите,
и при подсчёте этой самой статистики вы
будете использовать тот же алгоритм. Ваши
возможные действия? Оформить библиотечной
процедурой? Дело хорошее, но в расчёте той
статистики используются не только ваша
программа, но и программы других
разработчиков. И они - мыслят так же. Сколько
отдельных библиотек они создадут? Сколько
при этом образуется независимых «единиц
поддержки»? И как будет жить тот, кто в этих
условиях будет писать статистику? Вот если
бы у вас была возможность объявить свою,
находящуюся не в библиотеке, а прямо в
исполняемом модуле, процедуру доступной
для вызова из другого исполняемого модуля,
то вы бы убили сразу двух зайцев: 1) вам не
нужно поддерживать два файла вместо одного;
2) вам не нужно как-то специально
тестировать вашу библиотеку. Есть еще и
третье обстоятельство - эту процедуру из
вашего модуля «не выковырять», и, если у вас
есть какие-то алгоритмы, составляющие ваше
know how, то вам не нужно их помещать в
значительно более беззащитную объектную
библиотеку, которая, к тому же, может
распространяться отдельно от вашего модуля.
И - отдельно от вашего гордого имени тоже.
Вместо
всего этого кошмара вы просто объявляете COM-объект,
находящийся внутри вашего исполняемого
модуля. Объявляете как его вызвать - и всё.
Более того, если компьютер статистика
соединен с компьютером медсестры сетью, то
… то статистику даже не нужно иметь ваш
модуль на своей машине - он сможет его
запустить (и получить доступ к
функциональности вашего COM-объекта) на
машине медсестры со своей машины. Если вы с
уважением относитесь к авторскому праву, то
знаете, что программы не продаются (ввиду
очевидной глупости такого подхода), а
лицензируются для использования. Платить
приходится, фактически, по числу
процессоров, которые могут исполнять
программу. Запуск на машине медсестры не
нарушает лицензионного соглашения, а
запуск второй копии на машине статистика -
нарушает его. Эта особенность программы
становится выгодной, если программа,
содержащая не часто используемую функцию,
стоит дорого. Конечно, для вас
обстоятельство, понуждающее клиента купить
вашу программу еще раз, - выгодно. Но,
подумайте, были бы вы в том же лагере, если
бы уже вы писали бы ту же статистику с
использованием функций из чужих программ?
Кроме
того, обратите внимание на вскользь
упомянутое обстоятельство. Ваша программа
запускается на процессоре медсестры по
команде процессора статистика. Т.е. в какой-то
момент времени используются мощности двух
процессоров. А суммарная мощность… В общем,
с использованием COM возможна и такая
специфическая область деятельности, как
написание распределенных приложений. Это -
программные комплексы специальной
архитектуры и конструкции, которые,
примитивно говоря, состоят из независимо,
но синхронизируемо выполняемых на разных
процессорах модулей. А со стороны -
производят впечатление согласованной
одной программы.
В
этом - пожалуй, самое большое преимущество COM. Вы знаете, что практически никогда не
встречается случай, когда бы ваша программа
в момент ее окончания была бы именно тем,
что вы представляли себе, когда начинали ее
писать. Изменения технического задания,
переделки во внутренней конструкции,
изменение требований заказчика - да мало ли
что может произойти, почему вдруг вашей
программе понадобилось стать другой. Если
вы работаете над большим проектом, то в
какой-то момент времени это становится
проклятием - вы не можете изменить что-то
без того, чтобы не «поплыло» что-то другое.
Если же ваш проект делается как «грамотный
COM», то фактически, вы разбиваете его на
много согласованно работающих, но
самостоятельных частей. Причем -
несущественно, работают ли эти части на
одной машине или на нескольких… Конечно, и
здесь не все так просто, но
переконфигурирование безусловно проще
переписывания и последующего
полнообъёмного тестирования. Что делает COM
очень удобной архитектурной платформой для
проектов, масштаб которых заранее не очень
понятен и впоследствии может измениться.
Кроме
того, поскольку сопрягаются двоичные
объекты, - не все ли равно на каком языке эти
объекты написаны?! Кроссплатформенная
совместимость - бич Божий, кроме обмена
примитивными типами и вызова примитивных
процедур, как правило, двинуться не удается
- не знает компилятор Pascal или Visual Basic как
вызывать класс из модуля, написанного на C++.
А что такое COM-объект - все они прекрасно
знают. Более того, пользователи VB могут с
удовлетворением отметить, что все
идентификаторы, которые они с любовью
разделяют в тексте точками, обозначая
цепочечную ссылку, фактически являются COM-объектами.
Т.е. для того, чтобы в обиход VB ввести «свой»
объект его нужно сделать COM-объектом. И - всё.
Прочитав
это читатель вправе засомневаться - так
хорошо в одном месте не бывает. И будет прав
- помимо таких больших достоинств
технология COM имеет и немалые недостатки. О
которых - в следующий раз.