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

Question

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

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

---

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

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

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

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

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

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

Заранее благодарю вас за уделенное время!

Answer 1

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

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

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

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

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

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

Answer 2

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

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

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

Answer 3

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

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

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

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

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

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

Answer 4

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

Answer 5

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

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