Ile klas powinienem umieścić w jednym pliku? [Zamknięte]

Jestem przyzwyczajony do modelu Java, w którym możesz mieć jedną klasę publiczną na plik. Python nie ma tego ograniczenia i zastanawiam się, jaka jest najlepsza praktyka w organizowaniu zajęć.

Plik Python nazywa się „modułem” i jest to jeden ze sposobów porządkowania oprogramowania, tak aby miał „sens”. Kolejny to katalog zwany „pakietem”.

Moduł to odrębna rzecz, która może mieć jeden lub dwa tuziny blisko spokrewnionych klas. Sztuczka polega na tym, że moduł jest czymś, co zaimportujesz, i potrzebujesz, aby ten import był całkowicie sensowny dla osób, które będą czytać, konserwować i rozszerzać twoje oprogramowanie.

Zasada jest następująca: moduł jest jednostką ponownego użycia .

Nie możesz łatwo ponownie użyć jednej klasy. Powinieneś być w stanie ponownie użyć modułu bez żadnych trudności. Wszystko w bibliotece (i wszystko, co pobierasz i dodajesz) jest modułem lub pakietem modułów.

Na przykład pracujesz nad czymś, co czyta arkusze kalkulacyjne, wykonuje obliczenia i ładuje wyniki do bazy danych. Jak ma wyglądać Twój główny program?

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 )

Pomyśl o imporcie jako sposobie organizowania kodu w koncepcje lub fragmenty. Dokładna liczba klas w każdym imporcie nie ma znaczenia. Liczy się ogólna organizacja, którą przedstawisz w swoich importwypowiedziach.

Ponieważ nie ma sztucznego limitu, tak naprawdę zależy to od tego, co jest zrozumiałe. Jeśli masz grupę dość krótkich, prostych klas, które są logicznie pogrupowane razem, wrzuć kilka. Jeśli masz duże, złożone klasy lub klasy, które nie mają sensu jako grupa, przejdź do jednego pliku na klasę. Lub wybierz coś pomiędzy. Refaktoryzuj, gdy wszystko się zmienia.

Zdarza mi się lubić model Java z następującego powodu. Umieszczenie każdej klasy w osobnym pliku ułatwia ponowne użycie, ułatwiając przeglądanie klas podczas przeglądania kodu źródłowego. Jeśli masz grupę klas zgrupowanych w jednym pliku, inni programiści mogą nie być oczywiste, że istnieją klasy, których można użyć ponownie, przeglądając strukturę katalogów projektu . Dlatego jeśli uważasz, że twoja klasa może być ponownie wykorzystana, umieściłbym ją we własnym pliku.

Zależy to całkowicie od tego, jak duży jest projekt, jak długo trwają klasy, czy będą używane z innych plików i tak dalej.

Na przykład dość często używam serii klas do abstrakcji danych - więc mogę mieć 4 lub 5 klas, które mogą mieć tylko 1 linię długości ( class SomeData: pass).

Głupio byłoby podzielić każdy z nich na osobne pliki - ale ponieważ można ich używać z różnych plików, umieszczenie ich wszystkich w osobnym data_model.pypliku miałoby sens, więc mogę to zrobićfrom mypackage.data_model import SomeData, SomeSubData

Jeśli masz klasę z dużą ilością kodu, być może przy niektórych funkcjach, z których korzysta, dobrym pomysłem byłoby podzielenie tej klasy i funkcji pomocniczych na osobny plik.

Powinieneś je tak ustrukturyzować, żebyś to robił from mypackage.database.schema import MyModel, a nie from mypackage.email.errors import MyDatabaseModel- jeśli importujesz rzeczy z sensu, a pliki nie mają dziesiątek tysięcy linii, poprawnie to zorganizowałeś.

Dokumentacja modułów Python zawiera przydatne informacje na temat organizowania pakietów.

Rozpadam się na części, gdy denerwuje mnie zaraźliwość plików i kiedy pożądana struktura powiązań zaczyna się naturalnie pojawiać. Często te dwa etapy wydają się zbieżne.

To może być bardzo denerwujące, jeśli rozdzielisz rzeczy zbyt wcześnie, ponieważ zaczynasz zdawać sobie sprawę, że wymagane jest zupełnie inne uporządkowanie struktury.

Z drugiej strony, gdy jakikolwiek plik .java lub .py dociera do ponad 700 linii, zaczynam się denerwować, próbując przypomnieć sobie, gdzie jest „ten konkretny bit”.

W przypadku Pythona / Jythona zależność cykliczna instrukcji importu również wydaje się odgrywać rolę: jeśli spróbujesz podzielić zbyt wiele podstawowych bloków konstrukcyjnych na osobne pliki, to „ograniczenie” / „niedoskonałość” języka wydaje się zmuszać do grupowania rzeczy, być może w dość rozsądny sposób.

Jeśli chodzi o podział na pakiety, to tak naprawdę nie wiem, ale powiedziałbym, że prawdopodobnie ta sama zasada irytacji i pojawienia się szczęśliwej struktury działa na wszystkich poziomach modułowości.

Powiedziałbym, aby umieścić w tym pliku tyle klas, ile można logicznie pogrupować, nie czyniąc go zbyt dużym i złożonym.