Архивы: по дате | по разделам | по авторам

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

Архив
автор : Александр Бакулин   12.06.2001

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

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

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

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

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

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

X-files

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

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

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

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

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

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

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

Немного отвлечемся: все знают о существовании сред быстрой визуальной разработки (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-плагинов… Так что собирать программы из кусочков можно уже и сейчас.

[i39932]


1 (обратно к тексту) - Заинтересовавшихся отсылаю к книгам. Для обзорного знакомства подойдет книга Д. Чеппела «Технологии ActiveX и OLE», изданная Microsoft Press. Для глубоко изучающих вопрос программистов подойдет книга Крейга Брокшмидта «Inside OLE» того же издательства.
2 (обратно к тексту) - Object Linking and Embedding - связывание и внедрение объектов.
3 (обратно к тексту) - Объект, описывающий окно.
4 (обратно к тексту) - Что-то это мне напоминает… Ах да, Mac OS! - Scout.
5 (обратно к тексту) - Uniform Data Transfer - реализуется на основе IdataObject.
6 (обратно к тексту) - Shell name space и Shell extensions.
7 (обратно к тексту) - Теперь он называется Virtual Commander 2000.
© ООО "Компьютерра-Онлайн", 1997-2024
При цитировании и использовании любых материалов ссылка на "Компьютерру" обязательна.