Как правильно организовать дерево зависимостей пакетов / модулей?

Question

Доброе утро,

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

Какова ваша стратегия для хорошего общего дизайна потенциально сложной и создаваемой библиотеки питонов? У вас есть интересные предложения?

Спасибо

Обновление:

Я действительно искал эмпирическое правило. Например, предположим, что это происходит ( init .py удалено для ясности)

foo/bar/a.py
foo/bar/b.py
foo/hello/c.py
foo/hello/d.py

Теперь, если у вас d.py импортирует bar.b и a.py импортирует hello.c, я бы посчитал это плохим параметром. Другой случай будет

foo/bar/a.py
foo/bar/baz/b.py
foo/bar/baz/c.py

предположим, что a.py и b.py import c. у вас есть три решения: 1) b импорт c, импорт baz.c 2) вы перемещаете c в foo / bar. a.py импорт c, b.py импорт .c 3) вы перемещаете c в другое место (скажем, foo / cpackage / c.py), а затем и a, и b импортируете cpackage.c

Я предпочитаю 3), но если c.py не имеет значения как отдельный модуль, например, потому что вы хотите оставить его "закрытым" в пакете bar, я бы предпочел перейти на 1).

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

Answer 1

"Я нарисовал диаграмму зависимостей импорта и планировал агрегировать классы по уровню слоя."

Python должен читать как английский (или любой другой естественный язык).

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

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

Сделать модули и пакеты очевидными и логичными, чтобы список импорта был очевидным, простым и логичным.

"Кроме того, я рассматривал некоторые модификации классов, чтобы уменьшить эти зависимости."

Уменьшение зависимости звучит технически и произвольно. Может и не быть, но звучит так. Без реальных примеров невозможно сказать.

Ваша цель - ясность.

Кроме того, модуль и пакет являются автономными единицами повторного использования. (Не классы; класс, но сам по себе обычно не используется повторно.) Ваше дерево зависимостей должно отражать это. Вы нацелены на модули, которые можно аккуратно и аккуратно импортировать в ваше приложение.

Если у вас много тесно связанных модулей (или альтернативных реализаций), тогда пакеты можно использовать, но использовать их экономно. Библиотеки Python относительно плоские; и в этом есть какая-то мудрость.

---

Редактировать

Односторонняя зависимость между слоями является существенной особенностью. Это больше о правильном дизайне программного обеспечения, чем о Python. Вы должны (1) спроектировать слои, (2) спроектировать так, чтобы между слоями были очень строгие зависимости, а затем (3) реализовать это в Python.

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

Answer 2

Это зависит от проекта, верно? Например, если вы используете конструкцию модель-представление-контроллер, ваш пакет будет структурирован таким образом, чтобы сделать 3 группы кода независимыми.

Если вам нужны какие-то идеи, откройте каталог site-packages и просмотрите часть кода в этих модулях, чтобы увидеть, как они настроены.

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

Answer 3

Вопрос очень расплывчатый.

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

module1.py:

import module2

module2.py:

import module1

Это не сработает!