Python: выбор между модулями и классами

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

  • Создайте отдельный файл appstate.py с глобальными переменными с функциями над ними. Сначала это выглядит нормально, но кажется, что я что-то пропустил в ясности моего кода.

  • Создайте класс AppState с функциями класса в файле appstate.py, все остальные модули определены определенными заданиями. Это выглядит хорошо. Но теперь я должен написать длинную строку, например appstate.AppState.get_user_list(). Более того, методы не столько связаны друг с другом. Я могу создавать отдельные классы, но это было бы слишком много классов.

EDIT: если я использую классы, я буду использовать классные методы. Я не думаю, что необходимо создать экземпляр класса для объекта.

ОТВЕТЫ

Ответ 1

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

Во всяком случае, чтобы избежать проблемы, вы всегда можете:

from myapp.appstate import AppState

Таким образом, вам больше не нужно писать длинную строку.

Ответ 2

Звучит как классическая загадка:-) В Python нет ничего грязного или постыдного в выборе использования модуля, если это лучший подход. В конце концов, модули, функции и т.п. Являются, по сути, первоклассными гражданами на этом языке и предлагают интроспекцию и другие свойства, которые многие другие языки используют для получения объектов.

Как вы описали свои параметры, это похоже на то, что в этом случае вы не слишком сумасшедшие в отношении подхода на основе классов.

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

Ответ 3

Второй подход существенно отличается от первого подхода, если у вас есть состояние приложения, хранящегося в экземпляре AppState, и в этом случае ваша жалоба не применяется. Если вы просто храните вещи в классе и используете методы static/class, ваш класс не отличается от модуля, и вместо этого он будет pythonic, чтобы иметь его как модуль.

Ответ 4

Рассмотрим следующий пример:

configuration
|
+-> graphics
|   |
|   +-> 3D
|   |
|   +-> 2D
|
+-> sound

Реальный вопрос: в чем разница между классами и модулями в этой иерархии, поскольку они могут быть представлены обоими средствами?

Классы представляют типы. Если вы реализуете свое решение с помощью классов вместо модулей, вы можете проверить графический объект для его правильного типа, но написать общие графические функции.

С помощью классов вы можете создавать параметризованные значения. Это означает, что можно инициализировать по-разному класс звуков с помощью конструктора, но трудно инициализировать модуль с различными параметрами.

Дело в том, что вы действительно что-то отличное от точки зрения моделирования.

Ответ 5

Я бы пошел с маршрутом классов, так как он лучше упорядочил ваш код. Помните, что для удобства чтения вы можете это сделать:

from appstate import AppSate

Ответ 6

Я бы выбрал второй вариант: уже использовал первый, теперь мне приходится рефакторировать, так как мое приложение развилось и ему нужно поддерживать более модульные конструкции, поэтому мне теперь нужно обрабатывать несколько одновременных "конфигураций".

Второй подход - это ИМО, более гибкое и будущее доказательство. Чтобы избежать более длинных строк кода, вы можете использовать from appstate import AppState вместо import appstate.

Ответ 7

Почему бы не пойти с экземпляром этого класса? Таким образом, вы, возможно, даже сможете использовать 2 разных сеанса, в зависимости от того, какой экземпляр вы используете. Это может сделать его более гибким. Возможно, добавьте в модуль какой-то метод get_appstate(), чтобы он инициализировал класс один раз. Позже, если вы захотите несколько экземпляров, вы можете изменить этот метод, чтобы в конечном итоге принять параметр и использовать какой-либо словарь и т.д., Чтобы сохранить эти экземпляры.

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

Я согласен, что было бы более pythonic использовать модульный подход вместо classmethods.

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