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

248

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

Я думаю, что это разумноquestion учитывая требования и соглашения других языков, а такжеanswer is & lt; определить модули и пакеты Python & gt; и помимо этого, это вопрос предпочтения (/ мнения) ". -that answer само по себе не мнение d3vid

Ваш Ответ

6   ответов
36

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

14

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

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

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

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

неработающая ссылка на документацию по модулям Python. Может бытьSection 6.4 Modules.Packages намеченная ссылка сейчас?
5

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

299

ваше программное обеспечение таким образом, чтобы оно имело «смысл». Другой - это каталог, называемый «пакет».

Модуль - это отдельная вещь, которая может иметь один или два десятка тесно связанных классов. Хитрость заключается в том, что модуль - это то, что вы импортируете, и вам нужно, чтобы этот импорт был совершенно понятен людям, которые будут читать, поддерживать и расширять ваше программное обеспечение.

Правило таково:a module is the unit of reuse.

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

Например, вы работаете с чем-то, что читает электронные таблицы, выполняет некоторые вычисления и загружает результаты в базу данных. Как вы хотите, чтобы ваша основная программа выглядела?

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

Выше рекомендации согласуются сdocs.python-guide.org/en/latest/writing/structure
Ха-ха, мне нравится "смысл" в цитатах.
Ответ, который фактически не отвечает на вопрос, а как насчет читабельности, трудно читать файлы с более чем 500 строками.
@cdleary: чувство одного человека - это безумие другого человека. Обычно вы можете определить разумные модули. Однако в большом приложении всегда существует множество аспектов анализа, и один человек будет ломать волосы нарезке и нарезании кубиками функциональности другого человека.
9

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

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

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

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

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

Похожие вопросы