Скільки класів потрібно помістити в один файл? [зачинено]


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
Ха-ха, мені подобається "сенс" у цитатах.
cdleary

27
@cdleary: Почуття однієї людини - це безумство іншої людини. Зазвичай ви можете визначити чутливі модулі. У великому застосуванні, однак, завжди є кілька вимірів аналізу, і одна людина розділить волоски на нарізки та виправлення функцій іншої людини.
S.Lott


4
Відповідь, яка насправді не відповідає на питання, що стосується читабельності, важко читати файли з більш ніж 500 рядками.
Ведмант

38

Оскільки немає штучної межі, це дійсно залежить від того, що є зрозумілим. Якщо у вас є купа досить коротких, простих класів, які логічно згруповані між собою, киньте в купу їх. Якщо у вас є великі, складні класи або класи, які не мають сенсу як група, перейдіть по одному файлу на клас. Або виберіть щось середнє. Рефактор, як все змінюється.


23

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


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

Особливо якщо ви їдете з Java на Python. Вони
закидали

14

Це повністю залежить від того, наскільки великий проект, тривалість занять, якщо вони будуть використовуватися з інших файлів тощо.

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


1
непрацююче посилання на документацію модулів Python. Можливо, розділ 6.4 Модулі. Пакети - це призначене посилання зараз?
cod3monk3y

9

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

Це може бути дуже прикро, якщо ви розділите речі занадто рано, тому що ви починаєте розуміти, що потрібно зовсім інше впорядкування структури.

З іншого боку, коли будь-який файл .java або .py отримує понад 700 рядків, я починаю постійно дратуватися, намагаючись запам'ятати, де "цей конкретний біт".

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

Щодо розбиття на пакети, я насправді не знаю, але я б сказав, мабуть, те саме правило роздратування і поява щасливої ​​структури працює на всіх рівнях модульності.


6

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

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.