Программные продукты и системы

Компонентный подход. Базовый инструментарий, использующийся для построения программ, сегодня является важнейшей и основной составляющей в различных группах разработки как в малых, так и в крупных проектах. Особенное значение базовый инструментарий имеет для последних, так как инерционность в таких проектах очень высока и архитектурные недоработки и слабые места базового инструмента могут повлечь серьезные проблемы в будущем. Поскольку область применения достаточно широка, то базовый инструментарий должен обладать гибкостью, высокой скоростью работы, требовать минимум ресурсов конечной операционной системы, кроме того, для внедрения новых звеньев необходима расширяемость [1].

Большинство разработчиков программного обеспечения при разработке приложений используют компонентную технологию, являющуюся развитием объектно-ориентированной технологии проектирования [2]. Она объединяет гибкость в выборе компонент, свойственную разработке приложения собственными силами, с надежностью кода и функциональной полнотой, проверенными многократным использованием, характерным для коммерческих программных продуктов. Более того, компонентная технология позволяет оперативно вносить изменения в существующее приложение, не нарушая его работоспособности [1]. При этом новые приложения могут работать с новыми модулями, а старые – с прежними, которые остаются в системе. Снимается проблема «унаследованных» систем (нет необходимости их полной замены для изменения или расширения функциональности, а значит, уменьшаются затраты на сопровождение и модернизацию приложений).

Компонентная модель Microsoft COM (Component Object Model). В СОМ объект характеризуется своим классом. Класс – это реализация некоторого множества интерфейсов. Множественное наследование интерфейсов не поддерживается, вместо этого объект может иметь несколько интерфейсов одновременно. В СОМ интерфейс может определяться путем наследования другого интерфейса. Для всех интерфейсов существует базовый интерфейс IUknown. Для того чтобы перейти от интерфейса базового типа к унаследованному интерфейсу или от одного из интерфейсов объекта к другому, клиент должен вызывать метод QueryInterface, определенный в базовом интерфейсе IUknown [5].

Для идентификации классов и интерфейсов в СОМ используются 16-байтный идентификатор GUID. Объект в СОМ – это экземпляр класса. Клиент получает доступ к объекту с помощью указателя на один из его интерфейсов. Связь между классом и множеством поддерживаемых им интерфейсов достаточно произвольна. Не существует заранее заданного отношения между идентификатором класса и конкретным набором интерфейсов, и разные экземпляры класса могут поддерживать разные подмножества интерфейсов. Идентификатор класса ссылается на конкретную реализацию, и фактический набор интерфейсов для данной реализации становится окончательно известным только на стадии выполнения.

Заимствованная из С++ модель интеграции на двоичном уровне с помощью таблиц функций имеет свои плюсы. Невидимая пользователю возможность замены реализаций объектов и высокая эффективность вызовов методов в пределах одного адресного пространства по аналогии с вызовом виртуальной функции в С++ являются положительными сторонами этой модели.

Существенный и, пожалуй, единственный недостаток COM – накладные расходы, связанные с созданием экземпляров классов. Создание экземпляра класса в COM подразумевает поиск модуля реализации по идентификатору объекта GUID в реестре, в котором находится реализация класса [4], происходит загрузка модуля и выделение памяти под экземпляр класса. Как известно, операции с реестром в системе Windows относительно долгие, выделение памяти – дорогостоящая процедура, как и загрузка модуля. Преимущества компонентного подхода сводятся на нет при построении на ее основе, например, различных разборщиков структурированных форматов данных, таких как архивы, почтовые сообщения, HTML-страницы, OLE-документы и др. Разбор таких структурированных данных влечет постоянное множественное создание экземпляров объектов, где будет происходить существенная потеря производительности. Загрузка модуля является необходимым этапом при создании объекта, а что касается поиска в реестре и выделения памяти, то можно попытаться обойтись без них.

Оптимизация и расширение COM. Автором разработана компонентная модель, устраняющая перечисленные недостатки модели COM. Основными идеями при построении модели являлись:

·                                        возможность создания объектов на памяти, предоставляемой извне;

·                                        возможность явного указывания файла модуля реализации при создании объекта.

Смысл данного подхода заключается в возможности предоставления памяти экземпляру класса, выделенной специальным образом, оптимальным для работы в каждом случае использования. Например, надо быстро создать экземпляр объекта определенного класса. Для этого можно использовать память стека, поскольку выделение памяти на стеке происходит очень быстро по сравнению с выделением блоков памяти малого размера стандартными средствами операционной системы. Но памяти стека может не хватить в ситуациях, когда требуется одновременное создание множества экземпляров разных классов, например, при разборе составных объектов контейнеров. В этом случае память можно выделять блоками большого размера по мере надобности, и уже из каждого блока резервировать место под каждый создаваемый экземпляр. Это будет значительно быстрее, чем выделение памяти под каждый экземпляр отдельно.

Возможность обращения к классу объекта путем явного указывания модуля уменьшает время создания объекта, так как не происходит сопоставление идентификатора объекта и его модуля реализации.

В разработанной модели, как и в COM, есть классы, у классов есть список поддерживаемых интерфейсов. На каждый интерфейс объекта есть счетчик ссылок. Все интерфейсы наследуются от IUnknown. В одном модуле могут быть реализованы один или более классов. Обеспечение защиты данных экземпляра класса от многопоточного доступа возлагается на саму компоненту, что дает возможность оптимальным образом реализовывать защиту от параллельного доступа и не терять излишне быстродействие выполнения объектов.

В компонентную модель были введены понятия статических и динамических интерфейсов класса. Статические интерфейсы предназначены решать задачи реализации функционала, не требующего создания экземпляров классов. Это экономит время, поскольку создание экземпляра требует дополнительного времени. Динамические же интерфейсы принадлежат экземплярам класса и решают те же задачи, что и в COM.

Была введена возможность явно указывать параметры при создании классов, в числе которых обязательно присутствует указатель на внешнюю память для решения задач создания на сторонней памяти. Кроме того, был стандартизирован способ получения информации о классе по произвольному интерфейсу, в том числе его уникальный идентификатор. Идентификаторы классов и интерфейсов такие же, как и в COM, то есть это всем известный GUID. Тем самым предоставляется возможность идентификации класса объекта, что востребовано при передаче параметров указателей на интерфейсы. Например, когда требуется преобразовать указатель произвольного интерфейса к какому-то определенному типу C++ класса реализации. Такие задачи можно решать и путем реализации отдельного интерфейса с последующей попыткой его запроса, но для программирования это не очень удобно, и код получается более громоздким и запутанным. Ведь концепция интерфейсов призвана обеспечить инкапсуляцию данных и реализации, а в данном случае это будет избыточно.

У каждого класса есть свой интерфейс входной точки IEntryPoint_…, в котором реализованы методы создания экземпляра класса с произвольными параметрами и методы получения необходимого размера внешней памяти. Метод создания класса может возвращать предопределенный интерфейс, чтобы облегчить его использование при программировании. Через интерфейс входной точки также можно получать статические интерфейсы. Аналогом интерфейса входной точки в COM является интерфейс фабрики классов, который тоже можно получить через него. Таким образом, при описании класса описывается его собственный интерфейс входной точки с собственным методом создания с параметрами.

Схема создания экземпляра класса такова: сначала происходит загрузка модуля в память и получается указатель на функцию DllGetClassObject, аналогично с COM; затем через эту функцию получается указатель на интерфейс входной точки нужного класса либо указатель на статический интерфейс и уже через интерфейс входной точки путем вызова метода создается экземпляр объекта.

Автором разработана и реализована компонентная модель, позволяющая эффективнее и проще использовать все преимущества компонентного подхода в программных комплексах любой сложности. Технология позволяет максимально быстро создавать экземпляры классов, делать более понятными описания интерфейсов и связей их с классами, упрощать оперирование интерфейсами. Технология является расширением модели COM фирмы Microsoft.

Список литературы

1.        Фаулер М. Рефакторинг: улучшение существующего кода. / Пер. с англ. - СПб.: Символ-Плюс, 2005. - 432 с.

2.        Гамма Э., Хелм Р., Джонсон Р., Влиссидес Дж. Приемы объектно-ориентированного проектирования. Паттерны проектирования. – СПб.: Питер, 2003. - 368 с..

3.        Деннинг А. ActiveX для профессионалов. - СПб.: Питер, 1998. - 624 с.

4.        Чеппел Д. Технологии ActiveX и OLE. / Пер. с англ. – М.: Русская редакция, 1997. – 320 с.

5.        Роджерсон Д. Основы COM. / Пер. с англ. – М.: Русская редакция, 1997. – 376 с.

6.        Рихтер Д. Windows для профессионалов (программирование в Win32 API для Windows NT 3.5 и Windows 95). / Пер. с англ. – М.: Издат. отдел «Русская редакция» ТОО «Channel Trading Ltd», 1995. – 720 с.