Możliwości dla klas Pythona zorganizowanych w różnych plikach? [zamknięte]
chcesz poprawić to pytanie? Zaktualizuj pytanie, aby mogło być odpowiedź z faktami i cytatami przez edytując ten post .
Zamknięte 7 lat temu .
Popraw to pytanieJestem przyzwyczajony do modelu Javy, gdzie można mieć jedną publiczną klasę na plik. Python nie ma tego ograniczenia i zastanawiam się, jaka jest najlepsza praktyka organizowania klasy.
6 answers
Plik Pythona nazywa się "modułem" i jest to jeden ze sposobów organizacji oprogramowania tak, aby miało "sens". Innym jest katalog, zwany "pakietem".
Moduł jest odrębną rzeczą, która może mieć jeden lub dwa tuziny ściśle powiązanych klas. Sztuczka polega na tym, że moduł jest czymś, co zaimportujesz i potrzebujesz, aby import był całkowicie rozsądny dla ludzi, którzy będą czytać, utrzymywać i rozszerzać Twoje oprogramowanie.
Reguła jest następująca: moduł jest jednostką ponownego użycia .
Nie możesz łatwo użyć jednej klasy. Powinieneś mieć możliwość ponownego użycia modułu bez żadnych trudności. Wszystko w bibliotece (i wszystko, co pobierasz i dodajesz) jest albo modułem, albo pakietem modułów.Na przykład pracujesz nad czymś, co czyta arkusze kalkulacyjne, wykonuje pewne 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 o sposobie organizowania kodu w koncepcjach albo kawałki. Dokładnie ile klas jest w każdym imporcie nie ma znaczenia. Liczy się ogólna organizacja, którą przedstawiasz swoimi wypowiedziami import.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2010-04-14 09:59:33
Ponieważ nie ma sztucznej granicy, to naprawdę zależy od tego, co jest zrozumiałe. Jeśli masz kilka dość krótkich, prostych klas, które są logicznie pogrupowane, wrzuć kilka z nich. Jeśli masz duże, złożone klasy lub klasy, które nie mają sensu jako grupa, przejdź do jednego pliku na klasę. Albo wybierz coś pomiędzy. Refaktor w miarę zmian.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2008-09-20 03:11:04
Tak się składa, że podoba mi się model Java z następujących powodów. Umieszczenie każdej klasy w pojedynczym pliku sprzyja ponownemu użyciu, ułatwiając wyświetlanie klas podczas przeglądania kodu źródłowego. Jeśli masz kilka klas pogrupowanych w jeden plik, może nie być oczywiste dla innych programistów, że istnieją tam klasy, które mogą być ponownie użyte po prostu przeglądając strukturę katalogów projektu. Tak więc, jeśli uważasz, że twoja klasa może być ponownie wykorzystana, umieściłbym ją we własnym pliku.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2011-10-24 16:50:01
Wszystko zależy od tego, jak duży jest projekt, jak długie są 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ę (class SomeData: pass).
Głupio byłoby podzielić każdy z nich na osobne pliki - ale ponieważ mogą być używane z różnych plików, umieszczenie ich wszystkich w osobnym pliku data_model.py miałoby sens, więc mogę zrobić from mypackage.data_model import SomeData, SomeSubData
Jeśli masz klasę z dużą ilością kodu, może z niektórymi funkcjami, których używa, dobrym pomysłem byłoby podzielenie tej klasy i funkcji pomocniczych na osobny plik.
Powinieneś uporządkować je tak, aby robić from mypackage.database.schema import MyModel, a nie from mypackage.email.errors import MyDatabaseModel - jeśli miejsce, z którego importujesz rzeczy ma sens, a pliki nie mają kilkudziesięciu tysięcy linii, dobrze to zorganizowałeś.
Dokumentacja modułów Pythona zawiera kilka przydatnych informacji na temat organizacji pakietów.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2008-11-30 06:57:32
Dzielę rzeczy, kiedy denerwuje mnie wielkość plików i kiedy pożądana struktura relacji zaczyna naturalnie wyłaniać się. Często te dwa etapy wydają się pokrywać.
To może być bardzo irytujące, jeśli dzielisz rzeczy zbyt wcześnie, ponieważ zaczynasz zdawać sobie sprawę, że wymagana jest zupełnie inna kolejność struktury.
Z drugiej strony, gdy jakiekolwiek .java czy plik. py dociera do ponad 700 linijek zaczynam się ciągle denerwować próbuję sobie przypomnieć, gdzie jest "ten konkretny kawałek".
W Pythonie/Jythonie okrągła zależność instrukcji import również wydaje się odgrywać pewną rolę: jeśli spróbujesz podzielić zbyt wiele współpracujących podstawowych bloków na oddzielne pliki, to "ograniczenie" / "niedoskonałość" języka wydaje się zmuszać do grupowania rzeczy, być może w dość rozsądny sposób.
Co do podziału na pakiety, To Nie wiem, ale powiedziałbym, że prawdopodobnie ta sama zasada irytacji i powstawania szczęśliwej struktury działa na wszystkich poziomach modułowości.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2011-11-11 18:49:05
Powiedziałbym, aby umieścić w tym pliku tyle klas, ile można logicznie pogrupować, nie czyniąc go zbyt dużym i skomplikowanym.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2008-09-20 03:08:45