Я привык к модели Java, где вы можете иметь один открытый класс на файл. У Python нет этого ограничения, и мне интересно, как лучше организовать занятия.
Я привык к модели 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
заявлениями.
Поскольку нет искусственного ограничения, оно действительно зависит от того, что понятно. Если у вас есть несколько довольно коротких, простых классов, которые логически сгруппированы, добавьте их. Если у вас есть большие, сложные классы или классы, которые не имеют смысла как группа, используйте один файл на класс. Или выбрать что-то среднее. Рефакторинг как вещи меняются.
Мне нравится модель Java по следующей причине. Размещение каждого класса в отдельном файле способствует повторному использованию, облегчая просмотр классов при просмотре исходного кода. Если у вас есть группа классов, сгруппированных в один файл, другим разработчикам может быть неочевидно, что есть классы, которые можно использовать повторно, просто просматривая структуру каталогов проекта . Таким образом, если вы думаете, что ваш класс может быть повторно использован, я бы поместил его в отдельный файл.
Это полностью зависит от того, насколько велик проект, как долго будут работать классы, будут ли они использоваться из других файлов и так далее.
Например, я довольно часто использую серию классов для абстракции данных - поэтому у меня может быть 4 или 5 классов, которые могут быть длиной только в одну строку ( 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 содержит полезную информацию об организации пакетов.
Я расстаюсь с вещами, когда меня раздражает размер файлов и когда естественная структура желательности начинает проявляться. Часто эти два этапа, кажется, совпадают.
Это может быть очень неприятно, если вы разделите вещи слишком рано, потому что вы начинаете понимать, что требуется совершенно другой порядок структуры.
С другой стороны, когда любой файл .java или .py достигает более 700 строк, я начинаю постоянно раздражаться, пытаясь вспомнить, где находится «этот конкретный бит».
В Python / Jython циклическая зависимость операторов импорта также, кажется, играет роль: если вы пытаетесь разделить слишком много взаимодействующих базовых строительных блоков на отдельные файлы, это «ограничение» / «несовершенство» языка, кажется, заставляет вас группировать вещи, возможно довольно разумным способом.
Что касается разделения на пакеты, я не знаю, но я бы сказал, что, вероятно, одно и то же правило раздражения и появления счастливой структуры работает на всех уровнях модульности.
Я бы сказал, чтобы поместить в этот файл столько классов, сколько можно логически сгруппировать, не делая его слишком большим и сложным.