* При перепечатке материалов ссылка на www.SeoLiga.ru обязательна! RSS



Модель СОМ
31 марта 2009

Компонентные технологии программирования основаны на контрактах — наборах
правил, определяющих взаимодействие между отдельными компонентами приложе-
ния. Модель компонентных объектов (СОМ) была первой попыткой компании
Microsoft формализовать контракты в качестве парадигмы программирования. Форма-
лизации контрактов содействовало также создание поддерживающей их платформы.
Парадигма программирования СОМ основана на представлении контрактов между ком-
понентами с помощью определений типов. До появления СОМ контракты между
компонентами были представлены всего лишь как точки входа функций. В этом от-
ношении модель СОМ была значительным прогрессом: динамическая загрузка кодов
и систем типов вводится в ней естественным образом.
Хотя объектная модель СОМ используется очень широко, внутреннее устройство
компонентов весьма сложно. Чтобы научиться разбираться в нем, придется потратить
по крайней мере несколько месяцев. Написание приложений с использованием ком-
понентов СОМ можно упростить, используя стандартные библиотеки, например биб-
лиотеку шаблонных классов (ATL) со своим набором готовых классов, шаблонов
и макросов. Язык Delphi также позволяет скрыть сложность инфраструктуры СОМ.
Однако всех проблем избежать все равно не удастся.
Несмотря на сложность конструкций, модель программирования СОМ выдержала
проверку временем. Она объединила уже получившие распространение концепции
(инкапсуляция, полиморфизм, а также разделение интерфейса и реализации) в уни-
фицированную технологию. Но СОМ — это не только модель программирования, но
и поддерживающая ее платформа. К сожалению, платформа оказалась слабым местом
СОМ. Чтобы модель СОМ стала общепринятой технологией программирования, ей
не хватило именно устойчивой платформы.
Для описания контрактов СОМ компания Microsoft определила и поддерживает не
один, а целых два формата обмена: язык определения интерфейсов (IDL) и библиоте-
ку типов (TLB). Каждый из них сам по себе не создает проблем, однако эти два фор-
мата не изоморфны, т.е. существуют конструкции, которые могут быть корректны
в одном формате и в то же время не иметь смысла в другом.
Можно было бы определить третий формат на основе объединения конструкций,
поддерживаемых обоими форматами. Однако это не устраняет, как минимум, двух
других критических проблем, связанных со способами описания контрактов в СОМ.
Во-первых, модель СОМ даже не пытается описать взаимозависимость компонен-
тов. Невозможно взять компонент СОМ и выяснить, какие другие компоненты необ-
ходимы для его нормальной работы. Из-за отсутствия информации о взаимозависимо-
стях крайне трудно понять, какие DLL-библиотеки необходимы для развертывания
приложения СОМ. Из-за этого также невозможно, не запустив приложение, выяс-
нить, какие версии компонента необходимы. Во-вторых, каждый формат описания
контрактов не обладает хоть какой-либо расширяемостью.
Но даже если бы появился идеальный унифицированный формат описания, мо-
дель СОМ осталась бы отягощенной еще одной проблемой, связанной с функциони-
рованием контрактов. Эта проблема не имеет отношения к способам описания кон-
трактов. Она кроется в самих контрактах.
Контракт компонентов СОМ основан на описаниях типов. Используемая в кон-
трактах система типов основана на подмножестве языка C++, гарантирующем пере-
носимость между компиляторами. Переносимость гарантируется не только для лекси-
ки языков программирования, но и для форматов представления данных. Здесь и воз-
никает главная проблема.
В модели СОМ контракт компонента является физическим (т.е. двоичным) кон-
трактом. Следовательно, компонент СОМ предъявляет жесткие требования к меж-
компонентным вызовам. Контракт СОМ требует точной дисциплины стека, исполь-
зуемого при вызове методов, точного смещения каждой структуры данных, переда-
ваемой в качестве фактического параметра метода, точной информации о механизме
размещения памяти, используемом вызываемым методом, а также точного формата
ссылки на объект. Таким образом, контракт СОМ — это всего лишь протокол форми-
рования кадров стека, полностью лишенный семантики приложения.
Перечисленные выше требования делают технологию СОМ трудной в использо-
вании даже для классных программистов. Физическая природа контрактов компо-
нентов СОМ особенно неудобна, когда дело доходит до версий компонентов.
Управление версиями — задача далеко не простая, даже когда выполняются только
семантические изменения.
Для решения проблем, связанных с контрактами СОМ и их определением, рабо-
тающие в Microsoft команды разработчиков СОМ и MTS создали новую компонент-
ную платформу, названную COM3. Вскоре после выбора имени различные группы
внутри Microsoft обнаружили, что на некоторых платформах Microsoft имя COM3
нельзя использовать в качестве имени каталога, поэтому его изменили на COR.
В процессе разработки использовались и другие имена — СОМ+, Runtime, Lightning,
URT. В итоге перед первым выпуском бета-версии технология была переименована
в CLR (Common Language Runtime — общеязыковая исполняющая среда).


Теги: курсы 1с программирование, языки программирования высокого уровня Borland Delphi

Статьи по теме:

Data Marts
Свойство Enabled
OnIndexMissing
Методы передачи данных в сетях ЭВМ
Определение готовности сокета
Компонент TQRMemo
ДОБАВЛЕНИЕ ВОЗМОЖНОСТЕЙ РЕДАКТИРОВАНИЯ
Свойство ForceNewColumn
IsDeleted
Событие AfterPrint для TQuickRep
Панель Spacing
Свойство BandType
Печать из полей базы данных
Организация взаимодействия устройств в сети
Свойство Font
| Borland Delphi | vitek |
 


Пн Вт Ср Чт Пт Сб Вс
1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30 31


     



Rambler's Top100

Данный сайт или домен продается ICQ: 403-353-727

© 2009 Seoliga.ru | Borland Delphi | Модель СОМ. Регион сайта: Москва и Санкт-Петербург