Как правильно писать "плагинное" приложение?

Question

[reanimatorzon]

Решил тут сделать веб-приложение такое, чтобы использовались плагины. Я на самом деле совсем не представляю форму ответа на мой вопрос, но возможно вы поделитесь ссылками по тематике «Как правильно писать „плагинное“ приложение?» или даже кто-нибудь напишет статью об этом на Хабр.

Answer 1

[VenomBlood]

Посмотрите в сторону MEF и Unity (если говорить про .net), позволят создавать достаточно хорошие расширяемые системы.
Если смотреть с более общей точки зрения, то «плагинабельность» — это достаточно широкая и проработанная тема.
Тут встают вопросы: какая именно плагинабельность вам нужна?

Нужно ли взаимодействие на базе SOA? нужна ли изоляция плагинов в отдельный домен? Можете ли вы обойтись простой структурой подлкючения модулей, или надо использовать шину сообщений? Нужно ли разграничение по уровням доверия и, соответственно, раздельный API?
Также вопрос по поводу инъекции зависимостей — будут ли ваши плагины больше отдельными модулями, или они будут тесно интегрироваться в существующую среду (например плагин переопределяющий нотификацию) и возможно использование DI.

Краткого совета «как писать» здесь быть не может, нужно знать задачу и все нюансы.
Если говорить просто о каком-либо фреймворке для обеспечения плагинабельности — почитайте статьи про MEF, они на английском, но дадут общее представление об одном из возможных путей решения проблемы.

Comments

[garifzyanov]

Еще можно посмотреть в сторону Prism.

Answer 2

[Алексей Сидоров]

Создаем либу, которая предоставляет общее sdk, обычно это набор абстрактных классов. Создаем класс Plugin, который содержит в себе необходимые точки входа, обычно это init для того, чтобы плагин сказал о том, что он умеет, load для того, чтобы плагин начал выполнять возложенные на него фичи и unload, для выгрузки. Далее делаем менеджер этих самых плагинов, который имеет в себе указатели на все доступные плагины, он уже разруливает что загружать, а что нет, а также разруливает всякие штуки наподобии зависимостей между плагинами.
Работать такая связка будет столь же быстро, как и монолитное приложение, зато каждый плагин будет являться лишь кирпичиком и можно будет гораздо проще отлаживать. Такого рода незначительно влияет на скорость загрузки приложения (необходимо таки делать некоторые лишние телодвижения в рантайме) и незначительно на объем потребляемой памяти. Можно организовать обмен эвентами между плагинами, но гораздо проще и быстрее сделать плагины реализациями некоторых интерфейсов, а обмен событиями использовать лишь в небольшой части плагинов, где это реально нужно.

Comments

[VenomBlood]

И что самое главное — это очень значительно влияет на гибкость приложения.
То что Вы описали подходит ДАЛЕКО не всем и не везде, а начинать изучать что-то надо всё же с обзора, а не с взятого с потолка решения.

[VenomBlood]

На гибкость — в негативном смысле.

[Руслан Нигматуллин]

подобный подход применяется довольно часто, и, как ни странно, прекрасно справляется со своими задачами, стоит посмотреть хотя бы на QtCreator

[Алексей Сидоров]

Ну сие есть одно из предложений и в большинстве случаев именно такой подход предпочтителен. Преимущества очевидны, недостатки тоже. С влиянием на гибкость категорически не согласен. Четко оформленные интерфейсы наводят некий порядок в тех местах, где нужен он, а не некая абстрактная гибкость. В большинстве своем всякие bloatware типа CORBA только ухудшают всё дело, также как и всякие системы, в которых плагины полностью изолированы друг от друга и для общения друг с другом используют общую шину сообщений. Такие вещи только на словах красивые, а на деле поди договорись о протоколе общения между модулями: система очень хрупкой получается даже несмотря на красивые слова о том, что падение в одном из модулей не приведет к падению всей системы. К падению может и не приведет, но с очень большой вероятностью приведет к отказу всей системы в смысле выполнения возложенных обязанностей.

Answer 3

[schursin]

А посмотрите API и доки любого подобного и 90% вопросов отпадут сами собой.

Answer 4

[MaratFM]

В случае с питоном можно посмотреть в сторону Zope 3 (он же BlueBream), а также на компонентную архитектуру trac, и как вариант на расширения для mercurial

Если кратко их описать, то получится следующее:
Zope 3 — базируется на интерфейсах и адаптерах, данная концепция ближе к интерфейсам в яве, мне показалось излишне нагроможденной, исчезает красота питона;
Trac — основывается на компонентах и точках расширения, практически каждый блок является компонентом и связывается с другими через точки расширения, причем компонент который объявляет точки расширения так же описывает интерфейс, который должен реализовывать компонент использующий его;
Mercurial — позволяет расширять функционал через определение дополнительных команд, остальные изменения в функционалы через специальный хуки (могу ошибаться, т.к. не изучал подробно).


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

Answer 5

[AlpenColt]

Всё зависит от ваших нужд и широты функционала плагина. Лучше всего посмотреть, как это реализовано в опенсорсных решениях, к примеру, могу посоветовать FireFox и расширения на XUL, как образец довольно гибкого способа изменения функционала приложения.

Также, стоит посмотрет в сторону шаблона Наблюдатель", который облегчит масштабируемость.