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






Я бы посоветовал поместить в этот файл столько классов, сколько можно логически сгруппировать, не делая его слишком большим и сложным.
Поскольку искусственного ограничения нет, это действительно зависит от того, что понятно. Если у вас есть группа довольно коротких простых классов, которые логически сгруппированы вместе, добавьте их в группу. Если у вас есть большие, сложные классы или классы, которые не имеют смысла как группа, переходите по одному файлу на класс. Или выберите что-то среднее. Рефакторинг по мере изменения вещей.
Файл Python называется «модулем», и это один из способов организовать ваше программное обеспечение так, чтобы оно имело «смысл». Другой - это каталог, называемый «пакетом».
Модуль - это отдельная вещь, которая может иметь один или два десятка тесно связанных классов. Хитрость в том, что модуль - это то, что вы импортируете, и вам нужно, чтобы этот импорт был совершенно понятен людям, которые будут читать, поддерживать и расширять ваше программное обеспечение.
Правило такое: модуль - это единица повторного использования.
Вы не можете легко повторно использовать один класс. Вы должны иметь возможность повторно использовать модуль без каких-либо трудностей. Все в вашей библиотеке (и все, что вы загружаете и добавляете) является либо модулем, либо пакетом модулей.
Например, вы работаете над чем-то, что читает электронные таблицы, выполняет некоторые вычисления и загружает результаты в базу данных. Как вы хотите, чтобы ваша основная программа выглядела?
from ssReader import Reader
from theCalcs import ACalc, AnotherCalc
from theDB import Loader
def main( sourceFileName ):
rdr= Reader( sourceFileName )
c1= ACalc( options )
c2= AnotherCalc( options )
ldr= Loader( parameters )
for myObj in rdr.readAll():
c1.thisOp( myObj )
c2.thatOp( myObj )
ldr.laod( myObj )
Думайте об импорте как о способе организации вашего кода по концепциям или кускам. Не имеет значения, сколько именно классов содержится в каждом импорте. Важна общая организация, которую вы изображаете своими заявлениями import.
Ха-ха, мне нравится "смысл" в цитатах.
@cdleary: Чувство одного человека - безумие другого. Обычно вы можете определять разумные модули. Однако в большом приложении всегда есть несколько измерений анализа, и один человек будет скучать по нарезке и нарезке функциональности другого.
Вышеуказанные рекомендации согласуются с docs.python-guide.org/en/latest/writing/structure
Ответ, который на самом деле не отвечает на вопрос, а как насчет удобочитаемости, трудно читать файлы, содержащие более 500 строк.
Это полностью зависит от того, насколько велик проект, какова длина классов, будут ли они использоваться из других файлов и так далее.
Например, я довольно часто использую серию классов для абстракции данных, поэтому у меня может быть 4 или 5 классов, длина которых может составлять только 1 строку (class SomeData: pass).
Было бы глупо разбивать каждый из них на отдельные файлы, но, поскольку они могут использоваться из разных файлов, было бы целесообразно поместить все это в отдельный файл data_model.py, поэтому я могу сделать from mypackage.data_model import SomeData, SomeSubData
Если у вас есть класс с большим количеством кода, возможно, с некоторыми функциями, которые он использует, было бы неплохо разделить этот класс и вспомогательные функции в отдельный файл.
Вы должны структурировать их так, чтобы вы использовали from mypackage.database.schema import MyModel, а не from mypackage.email.errors import MyDatabaseModel - если то, откуда вы импортируете вещи, имеет смысл, а файлы не состоят из десятков тысяч строк, вы все организовали правильно.
Документация по модулям Python содержит некоторую полезную информацию по организации пакетов.
неработающая ссылка на документацию по модулям Python. Может быть Раздел 6.4 Модули. Пакеты - теперь предполагаемая ссылка?
Мне нравится модель Java по следующей причине. Размещение каждого класса в отдельном файле способствует повторному использованию, облегчая просмотр классов при просмотре исходного кода. Если у вас есть группа классов, сгруппированных в один файл, для других разработчиков может быть неочевидно, что там есть классы, которые можно повторно использовать, просто просматривая структура каталогов проекта. Таким образом, если вы думаете, что ваш класс можно использовать повторно, я бы поместил его в отдельный файл.
Я полностью согласен с тобой. Наличие нескольких общедоступных классов в одном файле противоречит интуиции и затрудняет понимание кода, как будто кто-то хочет скрыть структуру и чувствует себя липким. Особенно, если вы перешли с Java на Python.
Особенно, если вы перешли с Java на Python. Раньше на Python кидали много классов в один файл)
Я обнаруживаю, что разбиваю вещи, когда меня раздражает размер файлов и когда желаемая структура взаимосвязи начинает вырисовываться естественным образом. Часто кажется, что эти два этапа совпадают.
Если вы разбиваете вещи слишком рано, это может быть очень неприятно, потому что вы начинаете понимать, что требуется совершенно другой порядок структуры.
С другой стороны, когда какой-либо файл .java или .py достигает более 700 строк, я начинаю раздражаться, постоянно пытаясь вспомнить, где находится «этот конкретный бит».
С Python / Jython циклическая зависимость операторов импорта также, кажется, играет роль: если вы попытаетесь разделить слишком много взаимодействующих базовых строительных блоков на отдельные файлы, это «ограничение» / «несовершенство» языка, похоже, заставит вас сгруппировать вещи, возможно довольно разумным образом.
Что касается разделения на пакеты, я точно не знаю, но я бы сказал, что, вероятно, одно и то же правило раздражения и появления счастливой структуры работает на всех уровнях модульности.
Я думаю, что это разумный вопрос, учитывая требования и соглашения других языков, а отвечать - это «<определить модули и пакеты Python> и помимо этого, это вопрос предпочтений (/ мнение)» - этот ответ сам по себе не является мнением