Как разработать модульное приложение?

Старайтесь, чтобы вещи были слабо связаны, и свободно используйте интерфейсы, чтобы помочь.

Я бы начал разработку с разделения проблем. Основные архитектурные слои:

• Проблемная область (также известная как Engine, Back-end): классы предметной области, которые выполняют всю фактическую работу, имеют знания предметной области, реализующие поведение предметной области.
• Постоянство: управление хранилищем для классов предметной области, уровень базы данных/файловой системы
• Пользовательский интерфейс: графический интерфейс, который взаимодействует с классами предметной области.
• Системные интерфейсы: общение с другими системами, например. сети, веб-сервисы

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

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

Я также хотел бы повторить то, что сказал MicSim, относительно тщательного проектирования интерфейса плагина и написания нескольких различных плагинов для его использования. Это единственный способ действительно конкретизировать проблемы взаимодействия приложения и плагинов.

Поскольку вы будете предоставлять некоторые базовые функции в своем приложении, убедитесь, что вы кодируете часть, которая должна быть расширяемой/заменяемой, уже в виде плагина самостоятельно. Тогда вы лучше всего поймете, как должен выглядеть ваш API.

И чтобы доказать, что API хорош, вы должны написать второй и третий плагин, потому что тогда вы обнаружите, что сделали много предположений при написании первого. Обычно все немного проясняется после выполнения 2-го и 3-го шагов.

Теперь вам нужно написать еще один плагин, потому что последние написанные вами плагины похожи на первый по типу, входным данным и представлению (может быть, еще один погодный веб-сервис). Выберите что-то совершенно другое, с совершенно другими данными, и вы увидите, что ваш API все еще слишком адаптирован. (В противном случае вы хорошо поработали!)

Ну, наверное, первое, с чего нужно начать, это сесть и выяснить, что может понадобиться плагину для выполнения его задачи.

Вы хотели бы рассмотреть два основных аспекта в вашем дизайне.

• Как ваш фреймворк будет передавать запросы/получать ответы от плагина?
• Какие вспомогательные классы или модули было бы полезно предоставить?

И, вероятно, также, поскольку это звучит как учебный проект.

• Что вы хотите написать сами, а что просто взять из существующей библиотеки?

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

• тщательно разработайте API для своего приложения (Как разработать хороший API и почему это важно)
• сделать все, что можно использовать независимо, модулем, затем сгруппировать и построить большие части из простых частей (KISS)
• не повторяйся (СУХОЙ)
• часто писать/публиковать краткую документацию для себя и других (мантра с открытым исходным кодом)...

Посмотрите на шаблон слушатель-подписчик. Рано или поздно ваше приложение станет настолько сложным, что вам потребуется реализовать обратные вызовы. Когда вы достигнете этого предела, используйте listener-subscriber (есть реализация в wxPython).

Например, несколько модулей захотят отслеживать новые данные из нескольких каналов. Модули, которые связаны друг с другом, могут захотеть обновить себя на основе новых данных.