Сколько классов я должен поместить в один файл? [закрыто]


274

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


8
Я думаю, что это разумный вопрос, учитывая требования и соглашения других языков, и ответ «<определить модули и пакеты Python> и далее, это вопрос предпочтения (/ мнение)» - этот ответ сам по себе не является мнением
david.libremone

Ответы:


333

Файл 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заявлениями.


24
Хаха, мне нравится "смысл" в цитатах.
cledary

27
@cdleary: чувство одного человека - безумие другого. Обычно вы можете определить разумные модули. В большом приложении, однако, всегда есть несколько измерений анализа, и один человек будет ломать волосы нарезке и ограничении функциональности другого человека.
S.Lott


4
Ответ, который на самом деле не отвечает на вопрос, а как насчет читабельности, трудно читать файлы с более чем 500 строками.
Ведмант

38

Поскольку нет искусственного ограничения, оно действительно зависит от того, что понятно. Если у вас есть несколько довольно коротких, простых классов, которые логически сгруппированы, добавьте их. Если у вас есть большие, сложные классы или классы, которые не имеют смысла как группа, используйте один файл на класс. Или выбрать что-то среднее. Рефакторинг как вещи меняются.


23

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


2
Я полностью согласен с тобой. Наличие нескольких открытых классов в одном файле противоречит интуитивному принципу и затрудняет понимание кода, подобно тому, как кто-то хочет скрыть структуру и чувствует, что его ставят в тупик. Особенно, если вы пришли с Java на Python.
WebComer

Особенно, если вы пришли с Java на Python. Раньше они бросали много классов в один файл в Python)
WebComer

14

Это полностью зависит от того, насколько велик проект, как долго будут работать классы, будут ли они использоваться из других файлов и так далее.

Например, я довольно часто использую серию классов для абстракции данных - поэтому у меня может быть 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 содержит полезную информацию об организации пакетов.


1
неработающая ссылка на документацию по модулям Python. Может быть, Раздел 6.4 Modules.Packages является предполагаемой ссылкой сейчас?
cod3monk3y

9

Я расстаюсь с вещами, когда меня раздражает размер файлов и когда естественная структура желательности начинает проявляться. Часто эти два этапа, кажется, совпадают.

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

С другой стороны, когда любой файл .java или .py достигает более 700 строк, я начинаю постоянно раздражаться, пытаясь вспомнить, где находится «этот конкретный бит».

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

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


6

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.