В моем приложении я должен поддерживать некоторые глобальные приложения и глобальные приложения, такие как подключенные пользователи, общее количество ответов, создание файла конфигурации приложения и т.д. Существует два варианта:
Создайте отдельный файл appstate.py с глобальными переменными с функциями над ними. Сначала это выглядит нормально, но кажется, что я что-то пропустил в ясности моего кода.
Создайте класс AppState с функциями класса в файле appstate.py, все остальные модули определены определенными заданиями. Это выглядит хорошо. Но теперь я должен написать длинную строку, например appstate.AppState.get_user_list(). Более того, методы не столько связаны друг с другом. Я могу создавать отдельные классы, но это было бы слишком много классов.
EDIT: если я использую классы, я буду использовать классные методы. Я не думаю, что необходимо создать экземпляр класса для объекта.
Второй подход кажется лучше. Я бы использовал первый только для файлов конфигурации или что-то в этом роде.
Во всяком случае, чтобы избежать проблемы, вы всегда можете:
from myapp.appstate import AppState
Таким образом, вам больше не нужно писать длинную строку.
Звучит как классическая загадка:-) В Python нет ничего грязного или постыдного в выборе использования модуля, если это лучший подход. В конце концов, модули, функции и т.п. Являются, по сути, первоклассными гражданами на этом языке и предлагают интроспекцию и другие свойства, которые многие другие языки используют для получения объектов.
Как вы описали свои параметры, это похоже на то, что в этом случае вы не слишком сумасшедшие в отношении подхода на основе классов.
Я не знаю, использовали ли вы среду Django, но если не посмотрите их документацию о том, как они обрабатывают параметры. Они являются приложениями, они определены в модуле, и они доступны во всем мире. То, как они анализируют варианты и раскрывает их во всем мире, довольно элегантно, и вы можете найти такой подход, вдохновляющий на ваши нужды.
Второй подход существенно отличается от первого подхода, если у вас есть состояние приложения, хранящегося в экземпляре AppState, и в этом случае ваша жалоба не применяется. Если вы просто храните вещи в классе и используете методы static/class, ваш класс не отличается от модуля, и вместо этого он будет pythonic, чтобы иметь его как модуль.
Рассмотрим следующий пример:
configuration
|
+-> graphics
| |
| +-> 3D
| |
| +-> 2D
|
+-> sound
Реальный вопрос: в чем разница между классами и модулями в этой иерархии, поскольку они могут быть представлены обоими средствами?
Классы представляют типы. Если вы реализуете свое решение с помощью классов вместо модулей, вы можете проверить графический объект для его правильного типа, но написать общие графические функции.
С помощью классов вы можете создавать параметризованные значения. Это означает, что можно инициализировать по-разному класс звуков с помощью конструктора, но трудно инициализировать модуль с различными параметрами.
Дело в том, что вы действительно что-то отличное от точки зрения моделирования.
Я бы пошел с маршрутом классов, так как он лучше упорядочил ваш код. Помните, что для удобства чтения вы можете это сделать:
from appstate import AppSate
Я бы выбрал второй вариант: уже использовал первый, теперь мне приходится рефакторировать, так как мое приложение развилось и ему нужно поддерживать более модульные конструкции, поэтому мне теперь нужно обрабатывать несколько одновременных "конфигураций".
Второй подход - это ИМО, более гибкое и будущее доказательство. Чтобы избежать более длинных строк кода, вы можете использовать from appstate import AppState вместо import appstate.
Почему бы не пойти с экземпляром этого класса? Таким образом, вы, возможно, даже сможете использовать 2 разных сеанса, в зависимости от того, какой экземпляр вы используете. Это может сделать его более гибким. Возможно, добавьте в модуль какой-то метод get_appstate(), чтобы он инициализировал класс один раз. Позже, если вы захотите несколько экземпляров, вы можете изменить этот метод, чтобы в конечном итоге принять параметр и использовать какой-либо словарь и т.д., Чтобы сохранить эти экземпляры.
Вы также можете использовать атрибуты свойств btw, чтобы сделать вещи более читабельными и иметь гибкость в хранении, как и где вы хотите сохранить.
Я согласен, что было бы более pythonic использовать модульный подход вместо classmethods.
Кстати, я не настолько большой поклонник наличия вещей, доступных во всем мире каким-то "волшебством". Я бы предпочел использовать явный вызов для получения этой информации. Затем я знаю, откуда берутся вещи и как отлаживать их, когда что-то не получается.