Преимущества сменной системы:
- расширяемость: приложение может динамически расширяться для включения новых функций.
- параллельная разработка: поскольку функции могут быть реализованы как отдельные компоненты, они могут разрабатываться параллельно различными группами.
- четкое направление развития: поскольку структура плагинов в идеале обеспечивает четко определенный интерфейс и документацию для авторов плагинов, у разработчиков есть четкий план развития.
- простота: плагин обычно имеет одну функцию, и поэтому разработчики имеют одну цель
Но некоторые из этих сильных сторон также являются слабыми сторонами:
- расширяемость: предвидит ли интерфейс плагина способы, которыми автор плагина расширяет приложение, или ограничивает расширение. Разработка расширяемости для удовлетворения всех вариантов использования часто занимает несколько итераций или чрезвычайно хороший анализ требований.
- ремонтопригодность: поставщик инфраструктуры плагинов должен не только убедиться, что интерфейс плагина удовлетворяет отступным сценариям использования, понятен и хорошо документирован, но также и что он может развиваться. Управление версиями и обратной совместимостью с существующими плагинами может быть очень сложным. Достаточно сложно, чтобы многие практические реализации не беспокоили, и заставляют авторов плагинов обновлять свои плагины с каждой версией.
- сложность: хотя каждый плагин работает, когда тестируется отдельно, взаимодействие между плагинами может вызвать новые проблемы, при этом ошибки появляются только при определенных комбинациях плагинов.
- тестирование: тестирование плагинов может быть затруднено, если система плагинов не предоставляет какую-либо форму запуска прогона плагинов для тестирования, что иногда невозможно, и тестирование доступно только при реальном запуске плагина, что замедляет разработку.
- искусственное разделение: плагин, как правило, имеет один фокус, но то, что составляет единый фокус, устанавливается поставщиком API плагина. Если автор плагина находит, что ему нужен плагин, который может разумно делать 2 вещи (как определено API плагина) в тесном тандеме, он может в конечном итоге реализовать два плагина и найти способы обеспечения связи между ними, которая в настоящее время не обеспечивается api. Затем ему приходится работать вокруг или против структуры плагинов.
Проектирование хорошей среды плагинов имеет много тех же проблем, что и проектирование хорошей библиотеки. Если вы сами создаете и среду, и плагины, то это не так уж и плохо, так как вы можете обновлять все плагины по мере развития среды, но если API плагина открыт для всех, тогда для разработки проекта требуется тщательное планирование и выполнение. право избегать слишком большого количества переписываний плагинов по мере развития среды.
" Синдром второй системы ", описанный Фредом Бруксом, утверждает, что разработанная вторая система часто является чрезмерно общей, стремясь к максимальной гибкости, иногда создавая "платформу внутри платформы" / " внутреннюю Эффект платформы". Встраиваемая конструкция часто рассматривается как выход, когда требования отсутствуют или занижены. Чтобы компенсировать это, программное обеспечение сделано настолько гибким, насколько это возможно, чтобы попытаться обработать «все, что приходит»
Приносим извинения, если это рисует тоскливую картину - подключаемые системы могут быть фантастическими и иметь много преимуществ, но они стоят дорого. Перед тем, как погрузиться в подключаемую систему, целесообразно составить требования ко всем плагинам, которые вам понадобятся для обеспечения требуемой функциональности. Это поможет вам решить, стоит ли использовать подключаемый дизайн или какой-то более простой подход будет одинаково полезен.