Каковы различные способы реализации системы плагинов?

Question

Я не ищу столько ответов для конкретного языка, сколько общие модели для реализации системы плагинов (если вы хотите знать, я использую Python). У меня есть своя идея (зарегистрировать обратные вызовы, и это все), но я знаю, что существуют другие. Что обычно используется, а что еще разумно?

Что вы подразумеваете под системой плагинов? Является ли Dependency Injection и контейнеры IOC хорошим решением?

Я имею в виду способ вставки функциональности в базовую программу без ее изменения. Я не собирался определять это, когда отправлялся. Инъекция зависимости не выглядит особенно подходящей для того, что я делаю, но я не знаю много о них.

Answer 1

Простая архитектура плагина может определять интерфейс плагина со всеми методами, которые должен реализовать плагин. Плагин обрабатывает события из приложения и может использовать стандартный код приложения, объекты модели и т. Д. Для достижения цели. По сути то же самое, что и форма ASP.NET, за исключением того, что вы переопределяете, а не внедряете.

Никто не учил меня этой части, и я не эксперт, но я чувствую: в общем случае плагин будет менее стабильным, чем его приложение, поэтому приложение всегда должно быть под контролем и давать плагину только периодические возможности действовать. Если плагин может зарегистрировать Observer, то вызовы делегата следует попробовать / перехватить.

Answer 2

Существует очень хороший эпизод из Радиоинженерии по программному обеспечению , который может вас заинтересовать.

Для дальнейшего использования я воспроизвел здесь « Правила для активаторов » ( альтернативная ссылка ), приведенные в превосходном Способствующем затмению Эрихом Гаммой Кент Бек.

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

Answer 3

В Python вы можете использовать систему точек входа, предоставляемую setuptools и pkg_resources. Каждая точка входа должна быть функцией, которая возвращает информацию о плагине - имя, автор, функции настройки и завершения и т. Д.

Answer 4

Как насчет абстрактной фабрики ? Ваша базовая программа определяет, как абстрактные понятия взаимодействуют друг с другом, но вызывающая сторона должна предоставить реализацию.