По COM звонит колокол…

Microsoft имеет достаточно много профессиональных наработок, и большинство из них хорошо задумано и зачастую неплохо реализовано. Об одной из них, а именно многокомпонентной модели объектов (COM) и пойдет разговор...

Это был бы сон, волшебный сон.
Каждый был бы просто чемпион,
Если мог бы выбирать себе коней.
«Машина времени»

Первым опытом создания shareware для меня стал файловый менеджер. Идея небогатая, но ничем не лучше и не хуже очередного блокнота или проигрывателя. Программа заняла свое место в ряду ей подобных, вскоре появились и отзывы — в большинстве своем неутешительные. Пришлось менеджера подлатывать, добавлять новые возможности, отзывы стали лучше, что подтолкнуло к выпуску новых версий. У версии 1.53 уже появились поклонники, версией 1.54 стали интересоваться покупатели. Находилось все больше интересных компонентов (писалось все это на Delphi), которые хотелось добавить в программу, расширяя ее функциональность. Да и пользователи требовали — сделай то, сделай это, добавь такую возможность… Программа росла как на дрожжах, увеличиваясь с каждой новой версией, и вскоре для индикации загрузки программы уже потребовался прогресс-бар.

Все это расширение возможностей не проходило для даром — баги прибавлялись с той же скоростью, что и фичи. Регулярные чистки кода и замена одних компонентов другими результатов не приносили, программа становилась все более монстрообразной, неповоротливой и неуправляемой…

Так всегда и выходит, когда программу пишут студенты с годичным опытом программирования, каким я был тогда — результат закономерен и неудивителен. Удивительно, когда подобные программы с тем же успехом пишут взрослые дядьки. Поскольку дядьки взрослые, то программы им тоже хочется писать взрослые — вот и получаются различные операционные системы весьма средней устойчивости и защищенности. Но самое интересное начинается, когда эти дядьки начинают продавать свои продукты. Феномен налицо: программу покупают, да еще как, и скоро, как на наркотике, на ней сидит почти весь мир!

X-files

На самом деле я совсем неплохо отношусь к Microsoft и даже не люблю плеваться в их сторону, как это делают большинство пользователей. Что толку ругать дождь? Он все равно от этого не прекратится…

Microsoft имеет достаточно много профессиональных наработок, и большинство из них хорошо задумано и зачастую неплохо реализовано. Об одной из них, а именно многокомпонентной модели объектов (COM) [1] я и хочу поговорить. COM выросла из технологии создания составных документов OLE [2], используемой для внедрения или связывания в документе различных таблиц, графиков, картинок и других объектов. Но в своем развитии многокомпонентная модель пошла дальше. Целью ее создания было решение основных проблем компонентного подхода: использования компонентов без наличия их исходного кода, взаимодействие объектов, написанных на различных языках программирования, наличие контроля версий и возможность подключения новых компонентов без перекомпиляции программы. Ключевыми понятиями в этой модели являются объекты, которые имеют «интерфейсы» — нечто весьма похожее на классы в программировании.

Основное преимущество COM в возможности «связывания на лету» разнообразных объектов, причем сами они друг о друге могут ничего не знать. Это очень мощный и надежный, хотя и достаточно сложный, механизм. При отсутствии нужного интерфейса у объекта COM-клиенты корректно переходят на использование более ранней версии этого интерфейса (вот он, контроль версий), а при отсутствии и ранней версии не «сломаются». Сейчас индустрия идет по пути создания грандиозных приложений, являющихся серверами COM, которые могут предоставить клиентам большое количество интерфейсов (примером может служить использование Word различными программами для формирования документов или «встраивание» IE в приложения для просмотра интернетовских страниц).

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

Мы наш, мы новый мир построим…

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

Работа программистов в этом случае сведется к написанию реализаций новых интерфейсов уже существующих объектов. Например, есть у нас редактор Write, выполненный в виде COM-сервера, а пользователю захотелось добавить к нему проверку орфографии. Купив реализацию соответствующего интерфейса, пользователь устанавливает его в системе (процесс должен быть не сложнее установки любой простейшей программы при помощи штатного инсталлятора). После этого в меню настроек Write появляется галочка «Включить проверку орфографии». Таким образом, пользователь может собрать программу, точно удовлетворяющую его нуждам. Программа будет строиться полностью по потребностям пользователя!

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

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

Немного отвлечемся: все знают о существовании сред быстрой визуальной разработки (VB, Delphi), в которых можно в качестве компонент использовать ActiveX. На сегодняшний день желание программистов облегчить свою участь привело к появлению большого числа «самодостаточных» ActiveX-компонент. Бросив на форму [3] несколько таких компонент и установив нужные свойства или связи между ними при помощи мыши, можно получить готовую программу, не написав ни строчки кода! Если уже сейчас таких компонентов достаточно много, то сколько же их появится при появлении компонентной ОС?

Кажется весьма логичным включить в состав подобной ОС визуальный конструктор, который позволит связать различные ActiveX-компоненты в приложение. Этот инструмент позволит пользователю создавать программы, не становясь программистом. Для продвинутых пользователей в систему можно включить скриптовой язык, который помогает манипулировать объектами. При минимальных затратах времени появляется возможность «собирать» что угодно — можно сделать хоть универсальный рабочий стол, на котором будет открываться содержимое папок, редактироваться и просматриваться содержимое файлов и Бог знает что еще [4]. Вашу фантазию почти ничто не ограничит!

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

Добавьте к вышеописанному единообразную передачу данных [5] — и мы получим нашу мечту. Согласитесь, идея собрать свой собственный Word весьма заманчива. При этом все свойства «офисности» по передаче данных между приложениями сохранятся, а настраиваемость возрастет в несколько раз. А представим себе, что вся структура пользовательского интерфейса, включающая окна и элементы управления, также построена на этой базе и может легко подменяться — различным shell replacement это и не снилось…

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

Обновление версии операционной системы сведется в этом случае к замене ядра, которое можно сделать практически «на лету» и, которое никоим образом не повлияет на сохранность данных и настроек приложений. Да и само обновление будет проходить по пути расширения API, а не украшательства системы — об этом будет кому позаботиться. Вполне возможно, что это позволит избежать значительной части ошибок в ОС. Хотя у подобной системы и останется одно наиболее уязвимое место — системный реестр (в случае потери его данных «знания» о взаимосвязях системы развалятся), но защитить его поможет своевременное резервное копирование (чем, кстати, занимается Windows при каждом выключении компьютера).

Так ли иллюзорна и утопична построенная нами картина? Как ни странно, нет! Посмотрим, что можно сделать на имеющемся материале. Microsoft предоставляет нам интерфейсы пространства имен оболочки и расширения оболочки [6]. Сюда же можно добавить возможность замены shell-а и службу Active Directory. Больших милостей от Гейтса ждать не приходится. Но и этого не так мало: сторонний производитель может описать объекты — периферийные устройства и другие части ОС типа файловой системы, наделив их необходимыми интерфейсами. Вполне выполнима и задача написания заготовок объектов для основных программ, а прототипы описанных визуальных конструкторов и скриптовые языки уже существуют.

С десяток энтузиастов вполне могут попытаться сделать shell-replacement, построенный по этим принципам, и при профессиональном подходе к написанию кода такая система даже будет работать, и у нее даже найдутся свои приверженцы, которые и будут продвигать ее в массы. И вот тут остается лишь одно «но»: любая, даже замечательно реализованная идея, еще не есть стандарт. Стандарты же, к сожалению, устанавливают не пользователи, а корпорации. Вряд ли удастся вывести такую систему в массы (если честно, то я не смог вспомнить аналогов данной ситуации за исключением создания Linux, хотя это достаточно косвенно относится к данному вопросу и отражает, скорее, уровень сложности системы), но попытка реализации этой идеи могла бы быть весьма интересной. Есть желающие?

***

А свой файловый менеджер [7] я довел до ума — оставил компактное и быстрое ядро для управления файлами и архивами, а все остальные потребности пользователей реализовал при помощи ActiveX-плагинов… Так что собирать программы из кусочков можно уже и сейчас.

[1] — Более заинтересованных читателей отсылаю к книгам. Для обзорного знакомства подойдет книга Д. Чеппела «Технологии ActiveX и OLE», изданная в Microsoft Press. Для глубоко изучающих вопрос программистов подойдет книга Крейга Брокшмидта "Inside OLE" того же издательства.
[обратно к тексту]

[2] — Object Linking and Embedding - связывание и внедрение объектов
[обратно к тексту]

[3] — Объект, описывающий окно
[обратно к тексту]

[4] — Что-то это мне напоминает... Ах да, MacOS! - Scout
[обратно к тексту]

[5] — Uniform Data Transfer - реализуется на основе IDataObject
[обратно к тексту]

[6] — Shell name space и Shell extensions.
[обратно к тексту]

[7] — Теперь он называется Virtual Commander 2000
[обратно к тексту]