Ранее мы уже затрагивали технические аспекты создания плагинов в Qt. В этот раз речь пойдет о теоретической стороне вопроса. Теперь перед нами стоит вопрос не "Как?", а "Зачем?"
Коротко вспомним, что же такое плагин. Плагин - опциональная динамическая библиотека, которая реализует заданный интерфейс. Это означает, что приложение, использующее плагины, состоит из ядра и подключаемых модулей. Эти модули не являются обязательными. Могут произвольным образом добавляться и убираться без пересборки всего проекта, и имеют минимальное число зависимостей между собой (в идеале - вообще не зависят друг от друга). При этом любой, кому известен интерфейс плагина, может создать свое подключаемое расширение для приложения, не имея доступа к исходным кодам проекта.
Из этого определения следует несколько плюсов и минусов от использования плагинов.
Начинаем, разумеется, с плюсов.
Добавлять поддержку плагинов в проект и не рассчитывать на этот плюс достаточно странно. Расширения от сторонних разработчиков - главная движущая сила роста возможностей и популярности вашего приложения в этом случае.
Вы создаете надежное ядро и минимальный набор качественных модулей. Открываете интерфейс плагина. И если все идет хорошо, то получаете множество дополнений, разработанных другими людьми. Таким путем идут многие известные IDE, графические редакторы и другие многофункциональные приложения.
Выход на опен-сорс для всего проекта не обеспечивает тех же преимуществ. Если приложение открыто, но не имеет простых способов добавления расширений, то пользователи либо будут довольствоваться версией "из коробки", либо выберут более "гибкое" решение. Подобная ситуация актуальна для графической оболочки dwm. Описание процесса установки "расширений" для dwm (а точнее - патчей) оказалось настолько сложным, что превратилось в полноценную статью.
Модульное приложение, состоящее из плагинов, на стороне пользователя обновить гораздо легче, чем монолитное. Технически это сводится к простому добавлению или замене одного или нескольких файлов библиотек расширений.
Поскольку плагины мало зависят друг от друга, то любой пользователь может скомпоновать приложение на свой вкус, как из конструктора. При этом он получает лишь то, что ему необходимо. Такое приложение-конструктор практически невозможно реализовать без использования плагинов - пришлось бы иметь тысячи сборок со всеми возможными комбинациями наборов функций (или получить неудобную систему патчей, как в dwm).
Не лишен подход на основе плагинов и недостатков.
Чем выше гибкость системы, тем сложнее ее реализовать и сопровождать. Причем, это проявляется на всех этапах разработки - от проектирования до написания кода.
Задача и правда довольно сложная. Без компромиссов не обойтись. Трудность заключается в следующем: как выбрать интерфейс плагина, который одновременно откроет все, что нужно, и при этом скроет все остальное. Так мы плавно переходим к следующему минусу.
Если не ограничивать свободу действий плагинов, то можно нарваться на проблемы безопасности. Ответственность за то, что творят плагины, несет разработчик и проектировщик ядра приложения. Всегда нужно помнить, что злоумышленник может подсунуть пользователю свой плагин под видом "хорошего". Если плагину все дозволено, то и случиться может все, что угодно, в зависимости от уровня полномочий пользователя, который запустил приложение.
Для решения этой проблемы нужно обеспечить понижение привилегий, с которыми будет работать плагин.
Удобно воспользоваться конструкциями языка программирования по обеспечению безопасности. Хороший пример - язык Java, который может похвастаться множеством систем и уровней защиты.
Другой вариант - разработка или использование для плагинов специального языка с более ограниченными возможностями, чем тот, на котором написано ядро (например, в Qt на C++ можно посмотреть в сторону QtScript). Реальный пример успешного использования такого подхода - текстовый редактор Vim. Сам он написан на C, но для создания расширений предусмотрен специальный язык Vim Script.
Если вы крайне серьезно относитесь к репутации вашего продукта, то можете пойти еще дальше, и заняться отбраковыванием "плохих" плагинов. Разработчики расширений должны пройти проверку качества, без которой их плагин не попадет в официальную базу данных. Подобное решение принято в App Store от Apple.
Теперь мы можем дать ответ на следующий вопрос: "Когда и что выносить в плагины". Если вы планируете часто обновлять приложение; давать пользователям свободу выбора относительно необходимого набора функций; предусмотреть возможность относительно простого добавления модулей от сторонних разработчиков, то плагины - ваш выбор.
Но не забывайте, что полноценная поддержка плагинов - это большая ответственность. Вы должны заранее побеспокоиться об универсальности, надежности и безопасности интерфейса плагина. Если рассмотренные преимущества вас интересуют не сильно, то гораздо проще ограничиться обычными динамическими (или статическими) библиотеками, которые явно будут линковаться в процессе сборки проекта. Так вы в разы упростите себе задачу и существенно сократите объем работы.
