Инкапсуляция

Динамическая компоновка

Требования к компонентам

Как уже отмечалось, поддержка замены компонента во время выполнения требует динамической компоновки. Чтобы понять, как это важно, лучше всего представить себе приложение, построенное из компонентов, которые не могут объединяться во время выполнения. Если Вы захотите изменить один из компонентов такой системы, Вам придется статически перекомпоновать или перекомпилировать программу и заново разослать ее пользователям. Приложение, собранное из компонентов, которые надо статически перекомпоновывать каждый раз при замене одного из них, эквивалентно приложению-монолиту.

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

Неважно, поддерживают ли компоненты и приложение динамическую компоновку, Вы разрушаете всю систему и должны перекомпилировать, если не переписывать, все заново.

Чтобы понять, как это связано с инкапсуляцией, нам необходимо определить некоторые термины. Программа или компонент, использующие другой компонент, называется клиентом (client). Используемый компонент в этом случае называют сервером (server). Клиент подсоединяется к компоненту-серверу через интерфейс (interface). Если компонент изменяется без изменения интерфейса, то изменений в клиенте не потребуется. Аналогично, если клиент изменяется без изменения интерфейса, то нет необходимости изменять компонент. Однако если изменение либо клиента, либо компонента вызывает изменение интерфейса, то и другую сторону интерфейса также необходимо изменить.

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

Необходимость изоляции клиента от деталей реализации накладывает на компоненты ряд важных ограничений:

1. Компонент должен скрывать используемый язык программирования. Любой клиент должен иметь возможность использовать компонент-сервер независимо от языков программирования, на которых написаны тот или другой. Раскрытие языка реализации создает новые зависимости между клиентом и компонентом. Независимость от языка программирования расширяет круг программистов, разрабатывающих и использующих компоненты. Это повышает конкурентоспособность продуктов и способствует более широкому распространению компонентной архитектуры

2. Компоненты должны распространяться в двоичной форме. Действительно, поскольку они должны скрывать язык реализации, их необходимо поставлять уже скомпилированными, скомпонованными и готовыми к использованию.

3. Должна быть возможность модернизировать компоненты, не затрагивая уже существующих пользователей. Новые версии компонента должны разработать как с новыми, так и со старыми клиентами.

4. Должна быть возможность прозрачно перемещать компоненты в сети. Необходимо, чтобы компонент и использующая его программа могли выполняться внутри одного процесса, в разных процессах или на разных машинах. Клиент должен рассматривать удаленный компонент так же как и локальный. Если бы с удаленными компонентами надо было работать иначе, чем с локальными, то потребовалось бы перекомпилировать клиент всякий раз, когда локальный компонент перемещается в другое место сети.

COM — это спецификация. Она указывает, как создавать динамически взаимозаменяемые компоненты. СОМ определяет стандарт, которому должны следовать компоненты и клиенты, чтобы гарантировать возможность совместной работы. Стандарты важны для компонентных архитектур так же, как и для любой системы с взаимозаменяемыми частями. Если бы не было стандарта на видеокассеты VHS, то найти подходящую ленту к Вашему видеомагнитофону было бы редкой удачей. Стандарты определяют диаметры резьбы для садовых шлангов и водопроводных кранов, на которые шланги надевают. Стандартам следуют платы PCMCIA и разъемы под них. Сигнал, принимаемый телевизором или радиоприемником, подчиняется стандарту. Стандарты особенно важны, когда разные части системы разрабатывают разные люди из разных организаций в разных странах. Без стандартов ничто не могло бы работать вместе. И у Microsoft есть внутренние стандарты, которым мы следуем при программировании (по крайней мере, большей частью).

Спецификация СОМ (COM Specification) — это документ, который устанавливает стандарт для компонентной архитектуры.

Дата добавления: 2014-01-05