Component Object Model: различия между версиями
[непроверенная версия] | [непроверенная версия] |
Содержимое удалено Содержимое добавлено
Луговкин (обсуждение | вклад) |
Луговкин (обсуждение | вклад) |
||
Строка 62:
* необходимость использования двух языков программирования (.idl для описания интерфейсов и, обычно, C++ для написания реализаций). Необходимость возникает только при создании собственных интерфейсов, и не возникает в случае, если разработчик ограничил себя использованием готовых интерфейсов.
* необходимость "прокладочного" кода (в его роли обычно выступает ATL) для того, чтобы создать COM-объект на базе С++ класса. Хотя этот код и тривиален в использовании для опытного человека, он не очень прост для начинающих. Как и в предыдущем пункте, эта проблема возникает только при написании собственных классов и не возникает при одном лишь использовании стандартных чужих классов (для которых MS разработал библиотеку смарт-пойнтеров
* необходимость регистрации компонент в реестре операционной системы, причем при этом в качестве идентификатора класса используется нечитаемый человеком [[GUID]] (хотя его и возможно дополнить читаемым именем).
* инфраструктура remoting (удаленного вызова методов) использует бинарный формат запросов и ответов, являясь расширением DCE RPC. Это приводит к возникновению огромной "поверхности уязвимости" с точки зрения безопасности, и не раз приводило к крупным эпидемиям вредоносного ПО (MSBlaster).
* инфраструктура remoting использует по умолчанию (вслед за DCE RPC) динамически назначаемые номера TCP- и UDP
* обработка ошибок. В COM принято использовать
Кроме того, runtime type information в COM, известная под названием type libraries, поддерживается только для т.н. Automation-compatible интерфейсов, имеющих огромные ограничения на типы параметров (массивы
Заметно, однако, что многие из этих недостатков являются платой за достоинство COM
С противоположной стороны, «истинно объектные» языки либо вообще не способны стыковаться с компонентами из других объектных языков и требуют написания всей системы (и нижележащих подсистем и фреймворков) «сверху донизу» на одном языке в одной исполняющей среде (Java, Objective C), либо же налагают такое же требование хотя и не на язык, но на исполняющую среду (.NET, языки C#, C++ managed и VB.NET).
Более новые аналогичные технологии (например, в мире .NET) пытаются решить эти проблемы. Там обычно стек remoting полиморфен и кастомизируем, что дает возможность самостоятельно выбирать формат вопросов/ответов и транспортный протокол (по умолчанию используется уже не DCE RPC, а [[SOAP]], в качестве формата данных
Использование механизма позднего связывания может существенно снизить производительность по сравнению, например, с вызовом экспортируемой функции из [[DLL|динамической библиотеки]]. Однако этот механизм применяется только в скриптовых языках, и только в том случае, если язык не поддерживает объявление ссылок на объекты как ссылок на COM-интерфейсы из type libraries (в виде Dim obj As Excel.Workbook), а поддерживает только абстрактные COM-объекты (в виде Dim obj As Object). Кроме того, такой же подход применяется в [[Objective C]] и [[Cocoa]].
|