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

Я ищу указатели, предложения, ссылки, предупреждения, идеи и даже анекдотические сообщения о том, как "разработать проект модульным способом". Я собираюсь использовать python для этого проекта, но совет не обязательно должен ссылаться на этот язык, хотя я готов реализовать проект на основе OOP.

Вот какой контекст, чтобы понять, откуда я родом, и чего я пытаюсь достичь...

Мой проект будет небольшим приложением, которое будет потреблять веб-службы и отображать результаты различными способами, в том числе:

всплывающее уведомление, содержащее только результат вызова
вкладка в главном окне приложения с графикой, построенной из извлеченных исходных данных
буфер сообщений (видимый на domand), где результаты различных служб будут накапливаться

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

На данный момент плагины должны, по сути, позволить разработчику активировать новый веб-сервис, определяя поставщика, манипулирование данными (если есть) и способ представления данных пользователю.

У меня есть большой опыт разработки drupal, который имеет мощный модульный подход, но это также следует за не объектно-ориентированным дизайном, поэтому я подозреваю, что для python дизайн drupal может быть не оптимальным решением.

Если это имеет какое-либо значение - ядро будет изначально разработано для GNU/Linux.

Заранее благодарим за ваше время!

Ответ 1

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

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

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

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

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

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

Ответ 2

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

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

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

Ответ 3

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

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

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

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

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

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

Ответ 4

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

Ответ 5

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

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