Каковы преимущества и недостатки основанной на плагине архитектуры?

Преимуществами подключаемой системы являются

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

Но некоторые из этих сильных сторон также являются слабыми:

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

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

« Синдром второй системы », описанный Фредом Бруксом, утверждает, что разработанная вторая система часто является чрезмерно общей, нацеленной на максимальную гибкость, иногда создавая «платформу внутри платформы» / » внутренний платформенный эффект ".Подключаемый дизайн часто рассматривается как выход, когда требования отсутствуют или не определены. Чтобы компенсировать это, программное обеспечение сделано настолько гибким, насколько это возможно, чтобы попытаться справиться с "всем, что приходит".

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