Estou acostumado com o modelo Java, onde você pode ter uma classe pública por arquivo. O Python não tem essa restrição e estou me perguntando qual é a melhor prática para organizar aulas.
Estou acostumado com o modelo Java, onde você pode ter uma classe pública por arquivo. O Python não tem essa restrição e estou me perguntando qual é a melhor prática para organizar aulas.
Respostas:
Um arquivo Python é chamado de "módulo" e é uma maneira de organizar seu software para que faça "sentido". Outro é um diretório, chamado "pacote".
Um módulo é uma coisa distinta que pode ter uma ou duas dúzias de classes estreitamente relacionadas. O truque é que um módulo é algo que você importará, e você precisa que essa importação seja perfeitamente sensível às pessoas que irão ler, manter e estender seu software.
A regra é esta: um módulo é a unidade de reutilização .
Você não pode reutilizar facilmente uma única classe. Você deve poder reutilizar um módulo sem dificuldades. Tudo na sua biblioteca (e tudo o que você baixa e adiciona) é um módulo ou um pacote de módulos.
Por exemplo, você está trabalhando em algo que lê planilhas, faz alguns cálculos e carrega os resultados em um banco de dados. Como você quer que seu programa principal seja?
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 )
Pense na importação como a maneira de organizar seu código em conceitos ou pedaços. Exatamente quantas classes existem em cada importação não importa. O que importa é a organização geral que você está retratando com suas import
declarações.
Como não há limite artificial, isso realmente depende do que é compreensível. Se você tiver várias classes simples e curtas, agrupadas logicamente, jogue-as em várias. Se você tem classes grandes e complexas ou que não fazem sentido em grupo, vá um arquivo por classe. Ou escolha algo no meio. Refatorar como as coisas mudam.
Por acaso, gosto do modelo Java pelo seguinte motivo. A colocação de cada classe em um arquivo individual promove a reutilização, facilitando a visualização das classes ao navegar no código-fonte. Se você tiver um monte de classes agrupadas em um único arquivo, pode não ser óbvio para outros desenvolvedores que existem classes que podem ser reutilizadas simplesmente navegando na estrutura de diretórios do projeto . Portanto, se você acha que sua classe pode ser reutilizada, eu a colocaria em seu próprio arquivo.
Depende inteiramente do tamanho do projeto, da duração das classes, se elas serão usadas em outros arquivos e assim por diante.
Por exemplo, muitas vezes uso uma série de classes para abstração de dados - portanto, posso ter 4 ou 5 classes que podem ter apenas 1 linha de comprimento ( class SomeData: pass
).
Seria estúpido dividir cada um deles em arquivos separados - mas, como eles podem ser usados em arquivos diferentes, colocar tudo isso em um data_model.py
arquivo separado faria sentido, para que eu possa fazer isso.from mypackage.data_model import SomeData, SomeSubData
Se você tem uma classe com muito código, talvez com apenas algumas funções que ele usa, seria uma boa ideia dividir essa classe e as funções auxiliares em um arquivo separado.
Você deve estruturar-los de modo que você faz from mypackage.database.schema import MyModel
, não from mypackage.email.errors import MyDatabaseModel
- se onde está a importar coisas fazem sentido, e os arquivos não são dezenas de milhares de linhas, você organizou-lo corretamente.
A documentação dos módulos Python tem algumas informações úteis sobre a organização de pacotes.
Encontro-me dividindo as coisas quando fico irritado com a grandeza dos arquivos e quando a estrutura desejável de relacionamento começa a surgir naturalmente. Freqüentemente esses dois estágios parecem coincidir.
Pode ser muito irritante se você dividir as coisas muito cedo, porque você começa a perceber que é necessária uma ordem totalmente diferente da estrutura.
Por outro lado, quando qualquer arquivo .java ou .py está chegando a mais de 700 linhas, começo a ficar irritado constantemente tentando lembrar onde "esse bit específico" está.
Com Python / Jython, a dependência circular de instruções de importação também parece desempenhar um papel: se você tentar dividir muitos blocos de construção básicos cooperativos em arquivos separados, essa "restrição" / "imperfeição" da linguagem parecerá forçá-lo a agrupar coisas, talvez de uma maneira bastante sensata.
Quanto à divisão em pacotes, eu realmente não sei, mas eu diria que provavelmente a mesma regra de aborrecimento e emergência de uma estrutura feliz funciona em todos os níveis de modularidade.
Eu diria para colocar quantas classes puderem ser agrupadas logicamente nesse arquivo sem torná-lo muito grande e complexo.