1 / 18

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

О некоторых вопросах компонентной архитектуры программного приложения. Алексей Игнатенко. Что такое компонента ( plug-in) ?. Независимый программный модуль, обычно подключаемый на этапе выполнения программы. Преимущества компонентной архитектуры. Компонентная архитектура.

malise
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

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

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

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

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

  6. Простое решение • DLL: • IPlugin *createInstance(const char *); • Application: • IPlugin* pluginInstance = createInstance(“RendererPlugin”); • IRenderer* renderer = dynamic_cast<IRenderer>(pluginInstance)

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

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

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

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

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

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

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

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

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

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

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

  18. Как искать плагины? • Перебор файлов в папках • Конфиг-файл (XML – рекомендуется MS) • В реестре (пишется инсталлятором)

More Related