На главную страничку учебника Visual BasicКомпонентная Объектная Модель Компонентная Объектная Модель (СОМ) — архитектура промышленного стандарта для объектно-ориентированной разработки приложений и основа для формирования компонентов ActiveX. Компонент ActiveX — физический файл (например, .exe, .dll, .ocx), который содержит классы, представляющие определения объектов. Эти объекты можно подключать и использовать в приложении Visual Basic. Компоненты ActiveX позволяют программистам объединять в приложении порции кода многократного использования. Для решения общих задач, таких, как числовой анализ или формирование элементов пользовательского интерфейса, разработчик может создавать свои собственные компоненты ActiveX или использовать подключаемые компоненты Microsoft или сторонних разработчиков. При создании в приложении пользовательских решений можно объединять компоненты ActiveX с общими компонентами. Компонентная Объектная Модель Для формирования эффективных современных приложений-клиентов требуется иметь представление относительно компонентов сервера, используемых клиентом; требуется также понимание базовой технологии СОМ, посредством которой клиент соединяется с этими компонентами. С СОМ связаны два различных аспекта. Во-первых, спецификация СОМ обеспечивает определение (или модель) для объекта. Во-вторых, СОМ обеспечивает возможности для создания объектов и организации связи между клиентом и сервером. В этом разделе предлагается краткий обзор СОМ — мощного дополнения к комплекту инструментальных средств разработчика. Здесь описываются умолчательные интерфейсы, обеспечиваемые объектами СОМ, показывается, как объекты поддерживают связь с клиентами и как использовать клиенты при создании и использовании экземпляра объекта. Для лучшего понимания СОМ полезно ознакомиться со следующими терминами и определениями: Компонент — единица исполняемого кода, которая предоставляет некоторые функциональные возможности. Компоненты обеспечиваются серверами, которые представлены файлами .exe, .dll или .ocx. Серверы могут быть построены из одного или больше компонентов; компоненты обеспечивают шаблоны, из которых затем создаются объекты. Компонентная Объектная Модель определяет, как компоненты создаются и как приложения-клиенты соединяются с компонентами. СОМ также обрабатывает запросы из приложений-клиентов на создание объектов. Объект — комбинация кода и данных, которые могут обрабатываться как единица. Объект имеет период существования, то есть он создается и разрушается. Автоматика — часть спецификации СОМ, которая определяет стандартную методику создания компонентов и использования объектов. Объект Автоматики — объект, который предоставлен другим приложением или инструментальным средством программирования через интерфейсы Автоматики. Объекты Автоматики также известны как программируемые объекты. Программируемый объект может управляться программным способом посредством его методов и свойств (интерфейс объекта). Разработчику приложения-клиента объект предоставляет возможность ввода информации или запроса и обеспечивает вывод, но внутренняя организация объекта разработчику недоступна. Разработчики должны лишь понимать, как использовать предоставляемые объектом функциональные возможности. Эти функциональные возможности предоставляются через один или несколько интерфейсов. Интерфейсы — средства (свойства и методы), посредством которых приложения-клиенты сообщаются с компонентом. Краткая история СОМ Целью разработки идеологии СОМ было сделать приложения более настраиваемыми и гибкими, причем главной задачей была поддержка концепции, известной как связывание и внедрение объектов. Идея состояла в том, чтобы получать документ-ориентированное приложение, работая в котором, например, можно было бы редактировать электронную таблицу из текстового процессора. Версия Microsoft технологии связывания и внедрения объектов называется OLE. В первой версии OLE для поддержания связи между клиентом и компонентом использовалось нечто, именуемое DDE (Dynamic Data Exchange —динамический обмен данными). В OLE 1 ни о какой СОМ речи не шло. DDE был сформирован на верхнем уровне архитектуры передачи сообщений Windows. Технология DDE была далека от совершенства. DDE работает медленно и недостаточно гибко. Кроме того, трудно написать код для DDE, который работает правильно. Эти серьезные недостатки свидетельствовали о том, что поиски должны быть продолжены. Решением было СОМ. СОМ меньше по ресурсам, работает быстрее, значительно более устойчивая и гибкая чем DDE. Во второй версии OLE было модернизировано с использованием СОМ вместо DDE. Однако OLE было первой системой, разработанной на базе СОМ. В OLE не реализовано все то, что может обеспечить СОМ. OLE имеет репутацию системы, также работающей медленно и сложной в программировании. Впрочем, причина этих проблем — в реализации OLE, это не результат использования СОМ. Все же следует помнить, что в OLE сделана попытка реализовать многие прежде недоступные возможности. Посредством OLE можно помещать изображение из графической программы одного разработчика в текстовый процессор другого разработчика и редактировать его, не покидая текстовый процессор. Протокол OLE определяет многофункциональную связь между клиентом и компонентом. Компонент может многое, а приложение-клиент должно быть к этому готово. Это, однако, делает OLE очень трудным в программировании. СОМ — не компьютерный язык и не конкурирует с ними. Рассуждения относительно того, что лучше: C++ или СОМ или наоборот, не имеет никакого смысла, так как перед СОМ и C++ стоят разные задачи. СОМ сообщает программисту, как строить компоненты, и программист свободен в выборе языка, на котором он будет писать компоненты. Часто компоненты пишутся на C++. Сегодня это позволяет делать и Visual Basic. Компонентные приложения Исполняемая часть приложения часто состоит из единственного монолитного двоичного файла. После того как компилятор генерирует приложение, оно не изменяется, пока не будет скомпилирована следующая версия. Изменения в операционных системах, аппаратных средствах и желаниях заказчика вынуждают разработчика вносить изменения и перекомпилировать приложение. В этих условиях разработчики должны искать способы продлить период существования уже созданных приложений. Решение состоит в том, чтобы разбить монолитное приложение на отдельные части, или компоненты. По мере совершенствования технологий новые компоненты могут заменять существующие компоненты, формирующие приложение. Приложение — более не статичный объект, оно может развиваться с появлением более эффективных компонентов. Более того, из существующих компонентов может быть быстро построено полностью новое приложение.
Традиционно приложение разделялось на файлы, модули или классы, которые компилировались и компоновались для создания приложения. Формирование приложений из компонентов — процесс несколько иной. Компонент подобен мини-приложению; он поставляется упакованным, как функциональная порция двоичного кода, которая скомпилирована, скомпонована и полностью готова к употреблению. Монолитное приложение уступает место группе компонентов, которые для формирования приложения соединяются друг с другом в период выполнения. Изменение или расширение приложения — простой вопрос замены одного из этих составляющих компонентов его новой версией или другим компонентом. Разбиение монолитного приложения на компоненты поддерживается механизмами СОМ.
Компонентное приложение Облегчение настройки приложения Пользователи часто хотят иметь возможность настраивать приложение под свои потребности и вкусы. В случае монолитного приложения конечный пользователь должен все время общаться с программистом, давая ему заявки на реализацию того или иного пользовательского решения. Компонентные архитектуры облегчают настройку приложения, так как каждый компонент может быть заменен на другой, который лучше удовлетворяет потребностям пользователя. Предположим, что имеются компоненты, основанные на графических редакторах Paint и Photo Shop. На иллюстрации внизу Пользователь 1 сконфигурировал приложение, чтобы использовать Paint, в то время как Пользователь 2 предпочитает Photo Shop. Приложение может быть легко настроено добавлением новых компонентов или изменением существующих компонентов.
Библиотеки компонентов Одно из больших преимуществ компонентной архитектуры — быстрая разработка приложения. СОМ позволяет выбирать компоненты из библиотеки компонентов и складывать их вместе при формировании приложения, подобно строительным блокам. Построение приложений из стандартных частей долгое время было неосуществимой мечтой разработчиков программного обеспечения. Однако с появлением элементов управления ActiveX, ранее называвшихся элементами управления OLE, "процесс пошел". Программисты на Visual Basic, С, C++ и Java могут использовать преимущества элементов управления ActiveX для ускорения разработки своих приложений и Web-страниц. В приложениях, конечно, потребуется создавать также некоторые пользовательские компоненты однако большая часть приложения может быть сформирована с использованием стандяр тных компонентов. Требования к компонентам Преимущества использования компонентов непосредственно вытекают из их способности динамически подключаться и отключаться из приложения. Для достижения этой возможности компоненты должны отвечать двум требованиям. Во-первых, компоненты должны обеспечить возможность динамической компоновки. Во-вторых, компоненты должны скрывать (или инкапсулировать) подробности их реализации. Определить, какое требование является более важным, — значит решать проблему яйца и курицы. Каждое требование зависит от другого. Можно остановиться на таком определении: динамическая компоновка — определяющее требование для компонента, а скрывание информации — необходимое условие для динамической компоновки. Ниже эти два требования исследуются более подробно. Динамическая компоновка Для понимания важности динамической компоновки можно представить себе приложение, сформированное из компонентов, которые не могут связываться в период выполнения. Если нужно изменить один из компонентов в системе, потребуется статически повторно скомпоновать или перекомпилировать программу и затем перераспределить ее. Разработчик не может ожидать, что конечные пользователи его приложения смогут повторно скомпоновать и скомпилировать приложение самостоятельно. Даже если бы они знали, как это делать, у них, наиболее вероятно, неоказалось бы требуемого компилятора. Приложение, созданное из компонентов, которые должны статически перекомпилироваться каждый раз при необходимости внести изменения, эквивалентно монолитному приложению. Инкапсуляция Почему динамическая компоновка требует инкапсуляции? При формировании приложения компоненты соединяются друг с другом. Если требуется заменить компонент на новый компонент, необходимо отключить старый компонент от системы и затем подключить новый. Новый компонент должен подключаться тем же самым способом, что и старый компонент, иначе потребуется переписать код, перекомпилировать или повторно скомпоновать эти компоненты. В данном случае не имеет значения, поддерживают ли компоненты и приложение динамическую связь. Если изменяется способ соединения компонента с другими компонентами, нарушается система компонентов и, по крайней мере, придется перекомпилировать, если не переписать приложение. Для понимания, как все это связано с инкапсуляцией, нужно ввести некоторые определения. Программа или компонент, который использует другой компонент, называется клиентом. Клиент соединен с компонентом через интерфейс. Если компонент изменяется без изменения интерфейса, для клиента ничего не должно измениться. Аналогично, если изменяется клиент без изменения интерфейса, компонент не должен изменяться. Однако, если при изменении или компонента, или клиента изменяется интерфейс, другая сторона интерфейса также должна измениться. Следовательно, чтобы использовать преимущества динамической компоновки, компоненты и клиенты должны стремиться не изменять их интерфейсы. Они должны быть скрыты. Подробности относительно того, как реализованы клиент и компонент, не должны быть отражены в интерфейсе. Чем больше интерфейс изолирован от подробностей реализации, тем меньше вероятность того, что в результате изменения клиента или компонента изменится интерфейс. Если интерфейс не изменяется, изменение компонента не будет иметь никакого эффекта для остальной части приложения. Изоляция клиента от реализации компонента накладывает на компонент некоторые важные ограничения:
На главную страничку учебника Visual Basic | |||||||||||||||||||||||||||||
 |
| |
|
|
|