О некоторых вопросах компонентной архитектуры программного приложения

Содержание

Слайд 2

Независимый программный модуль, обычно подключаемый на этапе выполнения программы

Что такое компонента (plug-in)?

Независимый программный модуль, обычно подключаемый на этапе выполнения программы Что такое компонента (plug-in)?

Слайд 3

Преимущества компонентной архитектуры

Преимущества компонентной архитектуры

Слайд 4

Компонентная архитектура

Компонентная архитектура

Слайд 5

Отличие обычных DLL от компонент

Отличие обычных DLL от компонент

Слайд 6

DLL:
IPlugin *createInstance(const char *);
Application:
IPlugin* pluginInstance = createInstance(“RendererPlugin”);
IRenderer* renderer = dynamic_cast(pluginInstance)

Простое решение

DLL: IPlugin *createInstance(const char *); Application: IPlugin* pluginInstance = createInstance(“RendererPlugin”); IRenderer* renderer

Слайд 7

Одно из трех:
Нарушается безопасность типов
static_cast
Ограничивается применение плагинов
dynamic_cast
Необходима разработка сложной и ломкой кастомной

Одно из трех: Нарушается безопасность типов static_cast Ограничивается применение плагинов dynamic_cast Необходима
RTTI
QueryInterface
Необходимы дополнительные соглашения для поиска однотипных плагинов (по имени, например)

Недостатки простого решения

Слайд 8

Интерфейсы определяется в приложении
Для интерфейсов применяются соглашения COM
Плагины региструются сами в нужном

Интерфейсы определяется в приложении Для интерфейсов применяются соглашения COM Плагины региструются сами
месте системы

Предлагаемое решение

Слайд 9

Фабрики для плагинов

Фабрики для плагинов

Слайд 10

Application:
DLL:

Вариант 1, локальный

Application: DLL: Вариант 1, локальный

Слайд 11

Система разрабатывается с нуля для поддержки плагинов

Вариант 2, глобальный

Система разрабатывается с нуля для поддержки плагинов Вариант 2, глобальный

Слайд 12

А нужно ли поддерживать возможность работы из разных сред?
Версии интерфейсов / библиотек
Суперклассы

А нужно ли поддерживать возможность работы из разных сред? Версии интерфейсов /
- да/нет
Приведение типов
Подсчет ссылок
Как искать плагины?
События

Проблемы и размышления

Слайд 13

Если нет требований, чтобы плагины и/или основное приложение работали из разных сред,

Если нет требований, чтобы плагины и/или основное приложение работали из разных сред,
нет смысла поддерживать соглашения COM
Не нужны STDMETHODCALLTYPE, BSTR и т.п.
Можно выделять и удалять память в разных DLL (это стоит проверить)
Более того: можно использовать набор базовых неабстрактных классов и подключать общую библиотеку ко всем плагинам
Внимание: но нужно очень четко работать с версиями в этом случае!

А нужно ли поддерживать возможность работы из разных сред?

Слайд 14

Проверять версии
1) У библиотеки (DLL)
2) У плагина (интерфейса)
Как проверять?
Как поддерживать совместимость?
Старые

Проверять версии 1) У библиотеки (DLL) 2) У плагина (интерфейса) Как проверять?
плагины должны работать с новыми интерфейсами?
Новые плагины должны работать со старыми интерфейсами?

Версии интерфейсов / библиотек

Слайд 15

Функции:
запрос на информацию без создания экземпляра
= статические функции
Создание объекта = фабрика
Нужны

Функции: запрос на информацию без создания экземпляра = статические функции Создание объекта
ли?
Накладные расохды на создание/поддержку

Суперклассы

Слайд 16

Dynamic_cast
QueryInterface

Приведение типов

Dynamic_cast QueryInterface Приведение типов

Слайд 17

AddRef/Release – единственный вариант.
Есть ли другие возможности? Если нет, почему?

Подсчет ссылок

AddRef/Release – единственный вариант. Есть ли другие возможности? Если нет, почему? Подсчет ссылок
Имя файла: О-некоторых-вопросах-компонентной-архитектуры-программного-приложения.pptx
Количество просмотров: 96
Количество скачиваний: 0