Создаём систему плагинов, часть 1

Примечание 12.01.2011: эта серия не была закончена. То, что было написано, говорит скорее не про плагины вообще, а представляет собой глубокий "заныр" в детали DLL и BPL. Если вас интересуют именно плагины, то вместо этой серии почитайте вот эту серию постов.

Окей, я решил, наконец, написать какую-нибудь программку. Может быть Shareware. Может быть нет. Не знаю. Есть только пока несколько задумок.

Хочется сделать что-нибудь красивое в D2009 с применением всех тех новых возможностей Delphi.

Ну и, конечно же, как любая нормальная программка, моя софтина должна быть расширяемой за счёт плагинов. Не суть сейчас важно, плагины какого рода будут в ней - для старта нужна некая универсальная система, на базе которой можно легко собрать любые плагинчики, какие надо.

Для тех, кто мало знаком с темой плагинов, я быстренько пробежался по DK и нашёл вот такие статьи (сверху-вниз - от самого навороченного до голых DLL):

• COM-автоматизация. Не сказать, что совсем плагины, но что-то близкое.
• Плагины в виде COM-объектов.
• Плагины в виде пакетов + интерфейсы.
• Плагины в виде пакетов (bpl - packages).
• Плагины в виде DLL.

Давайте посмотрим, какие варианты у нас есть:

1. COM-объекты (2-я статья). По-первой прикидке вроде и неплохое решение, но уж как-то кажется оно мне тяжеловесным. Да и не силён я в COM, а тут же всякие нюансы нужно учитывать. И кроме того, мне не нравится идея отложенной выгрузки библиотеки, а не по требованию (да, я в курсе про проблемы явной выгрузки, но...). Посему: этот способ подождёт до лучших времён.

2. Голые DLL (5-я статья). Однозначно нет, т.к. недостатков здесь полно, а преимуществ нет вообще. К примеру, это проблемы с DLLMain. Обычное решение таких проблем выглядит так: не выполнять никакой работы в DLLMain (читай: в секциях initialization/finalization модулей, а также в begin/end dpr-файла), а выполнять её только по запросу. Первым действием после загрузки библиотеки плагина должен идти вызов функции инициализации, а первым действием перед выгрузкой - вызов функции освобождения. К сожалению, никакими средствами эту схему в Delphi для DLL вы не реализуете.

Помимо этой проблемы есть ещё проблема утомительного составления модулей импорта/экспорта, их корректной синхронизхации при модификации.

Но самое главное в плагинах в виде DLL - это контроль ошибок. Вы замучаетесь использовать здесь коды ошибок. Давно на голом WinAPI не писали? Будете делать плагины в виде чистых DLL - придётся вспомнить. А как же авторы плагинов, которые пишут в Delphi и слабо знакомы с WinAPI? Ну, обойдутся или придётся учиться.

3. Пакеты Delphi (4-я статья). В чистом виде - также однозначно нет. Потому что это явная привязка к Delphi. А плагины должны быть независимы от языка. Кроме того, здесь имеются серьёзные проблемы с сопровождением - при некоторых модификациях нужно полностью пересобирать все проекты.

4. ...и снова пакеты Delphi (нет статьи - можно считать улучшенным способом "голых DLL"). Дело в том, что пакет в Delphi - это просто обычная DLL, но с некоторыми достаточно интересными свойствами. Откинув те из них, что имеют отношение чисто к Delphi, мы увидим, что пакет - это DLL, у которой код инициализации/финализации в DLLMain сведён к минимуму, а весь реальный код повешен на две специальные функции: Initialize и Finalize. Каждую из этих функций можно вызвать после загрузки и до выгрузки, соответственно, таким образом, полностью избавляясь от проблем с DLLMain. Во, это то, что нам нужно. Если отбросить специфичную для Delphi шелуху, то пакет будет представлять собой DLL, в которой нет проблем с DLLMain. Заметим, что простое использование пакетов вовсе не привязывает нас к Delphi. Это будет зависеть от реализации (см. далее).

5. ...пакеты как DLL + интерфейсы ("почти" третья статья). Окей, в предыдущем пункте мы избавились от проблемы с DLLMain. Осталась самая малость: как реализовывать интерфейс между ядром и плагинами. Итак, у нас есть варианты:

• Функции. Хотя здесь нет проблем с межязыковой совместимостью, но всё же этот способ никуда не годится: фактически этим возвращаются все проблемы голых DLL, только что без проблемы с DLLMain.
• Объекты. Никуда не годится. Привязка к Delphi, со всеми вытекающими - как и при чистых пакетах.
• Интерфейсы. Во. Это уже что-то. Во-первых, здесь нет привязки к языку - интерфейсы доступны почти в любом языке под Win32 (а где их нет - то это исключение, подтверждающее правило; впрочем, я таких языков не знаю). Во-вторых, интерфейс позволяет работать по ООП со всеми преимуществами. Меньше и проблемы с импортом/экспортом. А самое главное, что интерфейсы позволяют (как и объекты) использовать для контроля ошибок исключения - через safecall-методы.
  
  Для тех, кто вообще слабо знаком с интерфейсами, можно почитать Использование интерфейсов или Урок 4. Сервер, кокласс, интерфейс и Урок 5. Интерфейс IUnknown (с небольшим уклоном в COM). Вопрос производительности.

Вот это наш вариант!

Итак, для себя я получил, что идеальный вариант был бы плагины в виде пакетов, которые используются как простые DLL, а интерфейс ядро-плагины построен на базе интерфейсов. Что необходимо для того, чтобы эта система была бы независима от языка? Да всего-то самую малость: не передавать по интерфейсам никакой информации, специфичной для Delphi или конкретной версии компилятора - объекты (особенно Application и Screen), строки типа AnsiString/String/UnicodeString и т.п.

Причём, при желании, эта схема может быть (опционально и даже частями) легко дополнена до схемы "чисто пакеты + интерфейсы".

Например, главное приложение и входящие в базовую поставку плагины могут быть скомпилированы с использованием run-time пакетов Delphi (т.е. разделять между собой базовые пакеты Delphi - rtl, vcl и т.п.). При этом суммарный размер приложения уменьшается за счёт повторного использования кода, находящегося в стандартных пакетах (либо же можно собрать свой собственный пакет run-time поддержки).

Но при этом пакеты используются только как средство повторного использования кода - никаких иных бонусов с них получать нельзя (например, общий менеджер памяти). Самое главное, не использовать в пакетах языко-зависимых возможностей, а использовать их только как DLL - тогда и не будет межязыковых проблем.

Тогда сторонние плагины легко могут быть написаны как "пакеты в виде DLL + интерфейсы".

Как выглядят такие "пакеты в виде DLL" в других языках? По-большому счёту это будет просто DLL. Если язык позволяет собирать DLL без проблем с DLLMain - ну и супер, это идеально. Если же нет - ну что-ж, нужно просто аккуратнее писать плагин и не усугублять ситуацию (работают же как-то плагины в виде DLL с проблемами в DLLMain - и ничего).

По-большому счёту, даже в Delphi можно собрать плагин как DLL-проект, а не пакет - и встроить его в эту систему. Лишь бы интерфейс у DLL совпадал. И всё будет работать на отлично - если только вы не будете перегружать секции initialization/finalization кодом, а будете использовать специально введённые функции инициализации.

Читать далее.