Одним из основных преимуществ использования программной среды, поддерживающей интерфейсно– ориентированное развитие, являлась возможность смоделировать, «что» и «как» делает объект, как две различные концепции. Рассмотрим следующую простейшую иерархию типов для Java:
interface IDog {
public void Bark();
};
class Pug implements IDog {
public void Bark( ){…}
};
class Collie Implements IDog {
public void Bark( ){…}
};
Поскольку оба класса – Collie и Pug – совместимы с интерфейсом IDog , то клиенты могут написать групповой код следующим образом:
void BarkLikeADog(IDog dog) {
dog.Bark(); }
С точки зрения клиента, эта иерархия типов практически идентична предыдущему примеру на C++. В то же время, поскольку метод Bark интерфейса IDog не может иметь реализации, между определением интерфейса IDog и классами Pug или Collie не существует связи. Хотя из этого следует, что как Pug, так и Collie должны полностью определить свое собственное представление о том, что означает «лаять» (bark), конструкторы Pug и Collie не обязаны интересоваться, какие побочные эффекты окажут их производные классы на основной базовый тип IDog.
Поразительное подобие между первой и второй волной заключается в том, что каждая из них может быть охарактеризована с помощью простого понятия (класс и интерфейс, соответственно). В обоих случаях катализатором успеха послужило не само понятие. Для разжигания интереса со стороны индустрии программирования в целом потребовалась еще одна или несколько ключевых программных сред.
Интересной стороной систем второй волны является то, что реализация рассматривается как черный ящик. Это означает, что все детали реализации считаются непрозрачными (opaque) для клиентов объекта. Часто, когда разработчики начинают использовать такие основанные на интерфейсах технологии, как СОМ, то уровень свободы, которую дает эта непрозрачность, игнорируется, что побуждает неопытных разработчиков весьма упрощенно рассматривать отношения между интерфейсом, реализацией и объектом. Рассмотрим электронную таблицу Excel, которая выставляет свои функциональные возможности, используя СОМ. Реализация класса электронной таблицы Excel выставляет около 25 различных интерфейсов СОМ, что позволяет ей применять множество основанных на СОМ технологий (Linking, Embedding, Inplace Activation, Automation, Active Document Objects, Hyperlinking и т. д.). Поскольку каждому интерфейсу требуется по четырехбайтному указателю виртуальной функции (vptr) на объект, объекты электронной таблицы заполняют около 100 байт служебными данными, в добавление к любому конкретному состоянию электронной таблицы, которое может потребоваться для хранения пользовательских данных. Поскольку данный объект электронной таблицы может состоять из весьма большого количества ячеек, эти 100 байт служебных данных погашаются сотнями килобайт, которые может потребовать большая таблица для управления содержимым каждой используемой ячейки.
Фактическая реализация электронной таблицы Excel осложняется тем, что к каждой отдельной ячейке электронной таблицы можно обращаться также через интерфейсы СОМ. С точки зрения СОМ каждый из интерфейсов ячейки представляет собой определенную идентификационную единицу СОМ и не может быть обнаружен с помощью опросов объекта электронной таблицы функцией QueryInterface. Вместо этого интерфейсы ячеек обнаруживаются путем использования одного из альтернативных интерфейсов (например, IOleItemContainer), которые объект электронной таблицы выставляет для своих клиентов. Тот факт, что теперь каждая ячейка раскрывается для клиентов через интерфейсы СОМ, означает, что разработчик Excel должен позаботиться о недопущении чрезмерного количества служебных данных, относящихся к СОМ. Рассмотрим объект электронной таблицы, состоящей из 1000 ячеек. Предположим для простоты вычислений, что каждой ячейке требуется в среднем по 16 байт памяти для хранения исходного состояния ячейки Excel. Это означает, что таблица из 1000 элементов потребляет примерно 16 000 байт памяти, не связанной с СОМ. Для этой таблицы 100 байт служебных записей указателя виртуальной функции, помещенных интерфейсами табличного уровня, оказывают очень малое влияние на потребление памяти. Однако поскольку каждая отдельная ячейка может самостоятельно выставлять примерно восемь отдельных интерфейсов СОМ, то для каждой ячейки 32 байта могут быть заняты для служебных записей, касающихся управления указателями виртуальных функций ячейки. При использовании простых технологий реализации, которые включены в большинство сред разработки СОМ, 1000-ячеечной электронной таблице понадобится примерно 32 100 байт памяти для указателей виртуальных функций, что примерно вдвое превышает объем памяти, занимаемой исходными данными Excel. Ясно, что такие служебные записи чрезмерны.
Для того чтобы понять, как команда разработчиков Excel решила данную проблему расхода памяти на указатели vptr , полезно вновь проверить отношения между состоянием и поведением, как оно обычно реализовано в СОМ. На рис. A.1 показан простейший объект СОМ в памяти. Отметим, что блок памяти, занимаемый объектом, состоит из указателей vptr и элементов данных. Можно рассматривать этот рисунок, считая, что элементы данных представляют состояние объекта, а указатели виртуальных функций – его поведение. В большинстве реализаций объектов эти два аспекта объекта записаны в непрерывном блоке памяти. Однако СОМ не настаивает на этом. СОМ просто имеет дело с указателями vptr , а управление состоянием предоставляет разработчику. СОМ вполне счастлив, если разработчик решит разместить состояние объекта и vptr в различных блоках памяти, как показано на рис. А.2. В конце концов, то, как происходит управление состоянием объекта, является всего лишь одной из деталей реализации, скрытой от клиента за стеной интерфейсов объекта.
Так как СОМ не требует, чтобы состояние объекта было размещено рядом с его указателями vptr, команда разработчиков Excel смогла значительно уменьшить потребление памяти. Рассмотрим отдельную ячейку электронной таблицы. Хотя для записи содержимого ячейки необходимо выделить 16 байт памяти, но 32 байта памяти, необходимых для vptr ячейки, не обязательно размещать в едином блоке памяти вместе с данными ячейки. Кроме того, если к ячейке не осуществляется доступ через ее СОМ-интерфейсы, то эти 32 байта памяти для vptr вообще не нужны. Это означает, что Excel может просто динамически размещать блоки памяти для vptr, по принципу «ячейка к ячейке» (cell-by-cell). Поскольку к большей части ячеек обращения через интерфейсы СОМ не будет никогда, это означает, что фактически в большинстве случаев не будет и затрат на vptr. Этот принцип создания «невесомых» объектов (flyweight objects), предназначенных для обеспечения поведения по необходимости, является вариантом «отделяемой» (tearoff) технологии, которая была впервые предложена в великолепной книге Криспина Госвелла «Сборник рецептов программиста СОМ» (Crispin Goswell. СОМ Programmer's Cookbook) ( http://www.microsoft.com/oledev). Обе эти технологии используют отложенное вычисление (lazy evaluation) для задержки выделения памяти указателям vptr.
Невесомые и отделяемые элементы являются технологиями разработки СОМ, однако сама СОМ не дает им полномочий и не поддерживает явно. Эти технологии возникли из необходимости эффективно управлять состоянием. При использовании СОМ для разработки распределенных приложений возникают дополнительные проблемы управления состоянием, в том числе исправление распределенных ошибок, безопасность, управление параллелизмом, уравновешивание загрузки и непротиворечивость данных. К сожалению, СОМ ничего не знает о том, как объект управляет своим состоянием, так что она мало может помочь в разрешении этих проблем. Хотя разработчики могут изобретать свои собственные схемы управления состоянием, имеются явные преимущества в построении общей инфраструктуры для развития объектов со знанием своего состояния. Одной из таких инфраструктур является Microsoft Transaction Server (Сервер транзакций фирмы Microsoft – MTS).