Comments on Блог GunSmoker-а: Разработка системы плагинов в Delphi

Молодец, Тверь. Такие отличные статьи редко встрет...

2012-02-14T16:27:29.364+04:00

Молодец, Тверь.
Такие отличные статьи редко встретишь.

Лениво править 7 демо-примеров... Исправление вста...

2012-02-03T12:27:51.346+04:00

Лениво править 7 демо-примеров... Исправление вставлю в 8-й.

Кстати, насколько я помню, это не единственный найденный и поправленный косяк - так что для практики лучше смотреть последний вариант примеров.

ЗЫ: Посмотрел исходники там тоже. :)

2012-02-03T12:19:21.086+04:00

ЗЫ: Посмотрел исходники там тоже. :)

Ага, перепутан. Поправил.

2012-02-03T11:54:59.643+04:00

Ага, перепутан.

Поправил.

Я может чего-то не понял, но вот этот код меня сму...

2012-02-03T11:51:10.086+04:00

Я может чего-то не понял, но вот этот код меня смущает.

if Length(FItems) >= FCount then // "Capacity"
SetLength(FItems, Length(FItems) + 64);

Не перепутан ли тут знак > со знаком < ?

Хотя и тут радужно не получается. Плагин не может...

2012-01-30T13:03:50.275+04:00

Хотя и тут радужно не получается.

Плагин не может сделать:
AnotherPlugin.DoSomething(Self)
а вынужден делать:
AnotherPlugin.DoSomething(ICore.GetStub(Self))

А в первом варианте получим трудноуловимые проблемы.

>>> можно поступить проще: на каждый п...

2012-01-30T12:58:44.900+04:00
>>> можно поступить проще: на каждый плагин создать объект-переходник с тем же интефейсом(IPlugin)

На словах мне нравится, но писанины будет... ого-го.

А вообще в большинстве программ не перезапуск - это не проблема.

>>Такое решение упрощает разработку ядра, но...

2012-01-21T17:42:32.500+04:00
>>Такое решение упрощает разработку ядра, но сильно затрудняет разработку самих плагинов.

Честно говоря не сильно усложняет. Если плагин работает в контексте основного потока то вообще никакой сложности. Всю реализацию загрузки/выгрузки можно впихнуть в сдк.
Если же плагин работает с несколькими потоками, то можно использовать Lock/Unlock в том же сдк при обращении к другим плагинам.

>>Для успешной выгрузки удобнее всего ответс...

2012-01-16T21:00:26.279+04:00
>>Для успешной выгрузки удобнее всего ответственными за "перезагрузку" плагинов сделать сами плагины.
Такое решение упрощает разработку ядра, но сильно затрудняет разработку самих плагинов. Код повсеместно становится жестко зависимым от архитектуры приложения, явное знание о плагинной структуре и сильные зависимости от конкретных версий конкретных плагинов (причем с возможностью исчезновения этих плагинов в любой момент) затрудняют как добавление функционала, так и его модификацию, и даже рефакторинг.
Передо мной стояла задача с прямо противоположными приоритетами - превратить несколько монолитных приложений в модульные с общим ядром и пересекающимся составом плагинов с минимальными модификация существующего кода. Позднее были добавлены требования ослабления зависимости между плагинами, дабы имел значение только реализованный функционал, а сам плагин без ущерба можно было заменить аналогичным (или несколькими аналогичными).

можно поступить проще: на каждый плагин создать...

2012-01-14T01:10:58.129+04:00
можно поступить проще: на каждый плагин создать объект-переходник с тем же интефейсом(IPlugin)
При взаимодействии между плагинами как правило нужно больше чем просто интерфейс IPlugin. Например у меня есть IPopupPlugin через который осуществляется работа со всплывающими окошками, с кучей методов и свойств. На каждый плагин писать либо свой переходник, либо придумывать "хак" на ассемблерном уровне по маршалингу.

можно поступить проще: на каждый плагин создать об...

2012-01-13T21:45:49.868+04:00
можно поступить проще: на каждый плагин создать объект-переходник с тем же интефейсом(IPlugin),
он единственный будет общаться с плагином напрямую, а всем остальным модулям/плагинам отдавать ссылку на него
тогда Unload/FixUp не нужны

Для успешной выгрузки удобнее всего отвественными ...

2012-01-12T20:50:49.327+04:00
Для успешной выгрузки удобнее всего отвественными за "перезагрузку" плагинов сделать сами плагины. Вообще всю ответственность за поддержание "связей" возлагать на сами плагины.
Просто в плагин добавляем пару методов:
IPlugin = interface
//.... некоторые методы
procedure Unload(plugin: IPlugin); safecall;
procedure FixUp(plugin: IPlugin); safecall;
end;

Менеджер перед выгрузкой плагина вызывает Unload у каждого загруженного плагина. Загруженный плагин должен сам определить использует ли он этот плагин или нет, если использует - освободить все ссылки на плагин. После менеджер может выгрузить dll с плагином, заменить, подгрузить обновленный плагин и вызывать FixUp передав новый плагин всем загруженным плагинам. Кому надо - получает ссылки на плагин.

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

Интересно. Для меня главной проблемой выгрузки был...

2012-01-12T11:42:59.168+04:00
Интересно.
Для меня главной проблемой выгрузки было следующее: если функционалом плагина пользуются другие плагины, то как безболезненно выдернуть его из живой системы?

На самом деле это только с виду тяжко. На практике...

2012-01-11T14:30:06.354+04:00
На самом деле это только с виду тяжко. На практике все довольно просто реализуемо (добавлением пары методов в IPlugins), если интересно - могу рассказать. Код ядра по выдергиванию тоже довольно простой.

MrShoor , "Горячая" выгрузка - это очень...

2012-01-11T13:17:57.355+04:00
MrShoor ,
"Горячая" выгрузка - это очень жестко.
У меня важно было другое - чтобы плагины минимально зависели друг от друга и способа загрузки с одной стороны и могли неограниченно пользоваться функционалом остальных плагинов - с другой, т.е. чистый конструктор лего.
В итоге дошло до выражения зависимостей через интерфейсы, а ядро определяло порядок активации и вычисляло циклические зависимости.
Горячей выгрузке, кстати, предлагаемая мной оптимизация не противоречит - просто добавляет новые обязанности, причем не к загрузчику - он тупой, а к ядру - оно обязано уметь выдергивать логический плагин из работающей системы на лету, что в любом случае тяжко.

Leo Bonart, я ни в коем случае не говорю что ваш п...

2012-01-11T13:00:56.033+04:00
Leo Bonart, я ни в коем случае не говорю что ваш подход плох. Для ваших задач возможно так сделать удобнее и логичнее. Но если задача простая, то не обязательно её усложнять. У меня например была задача: простейшая система плагинов, но чтобы плагины могли обновлятся и перезагружаться "нагорячую", без перезапуска приложения. Мне не нужна была гибкость, и меня вполне устраивала и устраивает система 1 модуль = 1 плагин. С фабрикой же будет 1 модуль = 1 фабрика = N плагинов. В этом случае мне нужно было бы предусмотреть выгрузку модуля через фабрику, а значит обучить фабрику выгружать созданные ей плагины, а ведь ссылки на IPlugin будут существовать за пределами модулей. И в данном случае фабрика будет только мешать, давая мне гибкость которая абсолютно мне не нужна.
Поэтому прежде чем вводить какой-либо механизм, нужно подумать нужен ли он вам конкретно, его ведь еще обслуживать надо будет, ну и не переуседствовать с гибкостью :)

MrShoor, COM мне ни к чему: он для плагинов уровн...

2012-01-11T10:45:23.070+04:00
MrShoor,
COM мне ни к чему: он для плагинов уровня системы с его регистрацией в глобальном реестре, внешней автоматизации с маршалингом между процессами, различными потоковыми моделями и т.п. и т.д.
Мои задачи - архитектура конкретного приложения на уровне разработки и сопровождения. И здесь разделение физики (загрузчик) и логики (плагины) очень помогает, причем в первую очередь для целей тестирования.
И да, я это реализовал и оно используется в практике коммерческой разработки моего работодателя.

Leo Bonart, вы стали на путь изобретения COM. Сейч...

2012-01-11T01:25:27.378+04:00
Leo Bonart, вы стали на путь изобретения COM. Сейчас "оптимизация" на фабрику класса... потом независимое размещение в дериктории, и поиск по записи в реестре...

На мой взгляд иногда можно обойтись и без такой оптимизации. Нужно просто определить какие возможности действительно могут понадобится. Эдак можно до абсурда дойти и изобрести DCOM, изобрести dot.net... И дело не в том что оптимизация плохая, да, она гибкая, но поддержка такой гибкой оптимизации (которая возможно никогда не понадобится) требует документации, требует дополнительной реализации, дополнительного тестирования.
Взять предложенную вами же реализацию через фабрики. Представим ситуацию, мы хотим плагины обновлять по интернету без перезапуска приложения, прямо на лету, а между плагинами есть допустим связи. Нужно разработать систему по выгрузке, и восстановления связей (fixup), а в случае с фабрикой нужно обучать фабрику каждого класса делать такой "финт". Лишняя реализация в каждый плагин.

Поэтому важно выбрать именно тот уровень гибкости архитектуры, который нужен именно в нашем случае и не переусердствовать.

Маленькая оптимизация: 1. Пусть библиотека плагино...

2012-01-09T15:26:52.822+04:00
Маленькая оптимизация:
1. Пусть библиотека плагинов экспортирует одну функцию, которая возвращает одну интерфейсную ссылку, экспортирующую фабрику плагинов.
2. Тогда функции для явной зачистки писать не надо - достаточно специфицировать для ядра удержание ссылки на фабрику до выгрузки, а финализацию либы выполнять в деструкторе фабрики.
3. Появляется возможность размещать плагины буквально где угодно - загрузчику достаточно уметь получать ссылку на фабрику, а каким способом - всего остального кода не касается. Например, помещение плагинов в один исполняемый файл полезно для предотвращения излишних модификаций конечными пользователями и облегчения тестирования и отладки (утечки памяти много проще искать для одного файла и Delphi 2007 очень любит падать при отладке dll и bpl)

Romkin, почему-то в Delphi интерфейсы используются...

2011-12-28T08:28:47.914+04:00
Romkin, почему-то в Delphi интерфейсы используются повсеместно совершенно без ссылок на COM. К чему-бы это? Потому что интерфейс - это просто запись (record) с указателями на методы.

BSTR (который в WideString) аналогично совершенно спокойно используется в WinAPI (который новый), снова без всяких посылок к COM (в функциях).

HRESULT (который safecall) - это практически де-факто (современный) стандарт обработки ошибок на кодах ошибок. Используется, опять же, повсеместно - не только в WinAPI (и снова - в функциях), но и API сторонних разработчиков.

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

(Насчёт библиотеки типов примеров привести не могу.)

Почему в таких случаях не выбирают COM? Потому что это больше, чем требуется в данном конкретном случае. Вот почему не выбрал его здесь и я.

Разумеется, сколько людей - столько и мнений. И кто-то другой вполне может выбрать для своей реализации COM - ради бога. Я совершенно согласен, что если ты попробуешь предусмотреть всё-всё-всё, то просто переизобретёшь COM (и тогда тебе изначально надо было бы его использовать). Но эта статья - про другой подход. Возможно, когда-нибудь много позже я напишу и про другие подходы (но - навряд ли). А кому интересно сейчас - я ссылочки в начале статьи привёл.

Основная причина, как я уже сказал, - кривая обучения. Если ты делаешь систему на базе COM, тебе мало того, что придётся объяснять всё то, что я уже тут сказал, так ещё и объяснять новые вещи, связанные с COM, про которые я не говорил. И мне кажется, что не все из них тривиальны.

В моей же статье из нетривиальностей разве что библиотека типов. WideString ведёт себя как обычная строка. Интерфейсы - это вообще родной механизм под Delphi (к примеру, интерфейсы не существуют в C++, там они представляются абстрактными классами). Вроде у меня ничего особо сложного нет.

Почему это имеет значение? Эта статья предполагается для начинающих. Основная её цель - дать пинок в нужную сторону. Потому что лично меня задолбало видеть доморощенные API в системах, построенные с использованием PChar, самоделкиных функций управления памятью и самоизобретёнными же способами обработки ошибок. И это в 2011-м году!

Эти люди не понимают, что те вещи, которые они обычно замечают в WinAPI (PChar-ы и т.п.), находятся там только потому, что этот API был сделан более 20 лет назад - он тянется из 16-битных Windows, а некоторый - ещё из OS\2! Определённо, за 20 лет правила изменились. Вам не нужно думать об этом, этом или этом и сотне других вещей. Поэтому, эта статья - попытка что-то с этим сделать.

У варианта системы плагинов с библиотекой типов ес...

2011-12-27T20:32:48.800+04:00
У варианта системы плагинов с библиотекой типов есть еще то преимущество, что при необходимости плагин можно вынести в отдельный процесс, COM сможет выполнить маршалинг.
Например, у меня возникла такая ситуация: по мере развития программы появилось множество плагинов от разных авторов, причем самого разного качества. Некоторые плагины портят память, в некоторых есть проблемы с загрузкой/выгрузкой в DllMain других DLL и т.п. В основном это все редко используемые плагины.
Чтобы повысить стабильность работы приложения, менеджер плагинов может запускать некоторые плагины в отдельных процессах.

>>> Это всё - достаточно легковесные в...

2011-12-27T17:51:59.254+04:00
>>> Это всё - достаточно легковесные вещи, которые от COM, считай, не зависят, а используются повсеместно. Поэтому их легко понять, с ними легко работать. И кривая для изучения будет плавной.
Не факт. В реализации того же COM в Delphi уже многое предусмотрено, та же обработка ошибок, к примеру. Да и статей куча, достаточно не описывать все досконально, а просто дать ссылки.
А здесь все вручную придется делать. SafeCallException перекрываться будет?
На мой взгляд как раз в этом варианте потребуется более глубокое понимание механизмов Delphi, что, впрочем, полезно.
COM же недаром вводит вещи, которые требуют изучения. Вот планируется UI, а как будет решаться вопрос с тем, что вызов к этому UI может идти из разных приложений, из разных потоков? Взять хотя бы случай когда запущены два экземпляра приложения. То же самое касается и обратных вызовов. А если захочется плагин-синглетон? Например, для доступа к COM-портам, к оборудованию.
Вообще с нетерпением жду следующей части :)

>>> С самого начала возник вопрос, по...

2011-12-27T16:49:52.958+04:00
>>> С самого начала возник вопрос, почему вместо массива плагинов не использовать TInterfaceList?

Да, почему я его не использовал: у меня всего два действия: добавить и удалить. Очень просто. Собственно мне показалось, что это немного и можно и написать. С учётом, что никаких других возможностей я не использую. Хотя с отдельным классом, конечно, правильнее.

>>> Но это, все равно морока, было бы...

2011-12-27T16:44:39.080+04:00
>>> Но это, все равно морока, было бы интересно узнать про замену оберток

Обёртки нужны в любом случае, вне зависимости от выбранной схемы реализации плагинов. Исключение не должно выйти за пределы возбудившего его модуля.

Другое дело, кто эти обёртки делает - вы или среда.

Я ещё поговорю про обработку ошибок.

Кстати, мне кажется вы отчёт неверно трактуете. Я поясню логику в следующей статье.

>>> С самого начала возник вопрос, почему вместо массива плагинов не использовать TInterfaceList?

Да никаких причин нет, можно использовать.

>>> если все на базе COM, то почему бы сразу не взять все механизмы, ту же обработку ошибок, COM категории и так далее?

Я от COM взял только три вещи:
- Интерфейсы
- BSTR/WideSrtring
- Библиотеку типов

Это всё - достаточно легковесные вещи, которые от COM, считай, не зависят, а используются повсеместно. Поэтому их легко понять, с ними легко работать. И кривая для изучения будет плавной.

Если же делать COM-объекты, то нужно учить именно COM: threading model, apartments, masrshaling, in-proc/out-proc, ... кучу вещей. Понятно, экспертом быть не нужно, но надо будет иметь обо всём этом какое-то представление, чтобы понимать что ты делаешь при создании и регистрации объектов. Согласись, что это существенно сложнее чем интерфейсы, строки и заголовочники.

Само собой, если делать приложение размера MS Word, то COM тут практически без альтернатив. Но для меньших программ - какие плюсы компенсируют сложность COM для изучения?

Это личное мнение - понятно, могу ошибаться.

Спасибо, очень интересно. С самого начала возник в...

2011-12-27T15:57:41.785+04:00
Спасибо, очень интересно.
С самого начала возник вопрос, почему вместо массива плагинов не использовать TInterfaceList?
Тогда не придется писать добавление и удаление. TPluginManager.UnloadPlugin вообще выглядит очень подозрительно, в первый момент я даже подумал что он ошибочен.
И второе, если все на базе COM, то почему бы сразу не взять все механизмы, ту же обработку ошибок, COM категории и так далее?

Comments on Блог GunSmoker-а: Разработка системы плагинов в Delphi

Молодец, Тверь. Такие отличные статьи редко встрет...

Лениво править 7 демо-примеров... Исправление вста...

ЗЫ: Посмотрел исходники там тоже. :)

Ага, перепутан. Поправил.

Я может чего-то не понял, но вот этот код меня сму...

Хотя и тут радужно не получается. Плагин не может...

>>> можно поступить проще: на каждый п...

>>Такое решение упрощает разработку ядра, но...

>>Для успешной выгрузки удобнее всего ответс...

можно поступить проще: на каждый плагин создать...

можно поступить проще: на каждый плагин создать об...

Для успешной выгрузки удобнее всего отвественными ...

Интересно. Для меня главной проблемой выгрузки был...

На самом деле это только с виду тяжко. На практике...

MrShoor , "Горячая" выгрузка - это очень...

Leo Bonart, я ни в коем случае не говорю что ваш п...

MrShoor, COM мне ни к чему: он для плагинов уровн...

Leo Bonart, вы стали на путь изобретения COM. Сейч...

Маленькая оптимизация: 1. Пусть библиотека плагино...

Romkin, почему-то в Delphi интерфейсы используются...

У варианта системы плагинов с библиотекой типов ес...

>>> Это всё - достаточно легковесные в...

>>> С самого начала возник вопрос, по...

>>> Но это, все равно морока, было бы...

Спасибо, очень интересно. С самого начала возник в...