español - python classes functions
¿Cuántas clases debo poner en un archivo? (6)
Como no hay límite artificial, realmente depende de lo que sea comprensible. Si tienes un grupo de clases bastante cortas y simples que se agrupan lógicamente, agrega un montón de ellas. Si tiene clases grandes o complejas que no tienen sentido como grupo, vaya un archivo por clase. O elegir algo en el medio. Refactorizar como las cosas cambian.
Estoy acostumbrado al modelo Java donde puede tener una clase pública por archivo. Python no tiene esta restricción, y me pregunto cuál es la mejor práctica para organizar clases.
Depende completamente de qué tan grande sea el proyecto, cuánto duran las clases, si se usarán de otros archivos y así sucesivamente.
Por ejemplo, a menudo uso una serie de clases para la extracción de datos, por lo que puedo tener 4 o 5 clases que pueden tener solo 1 línea ( class SomeData: pass ).
Sería estúpido dividir cada uno de estos en archivos separados, pero como pueden usarse desde archivos diferentes, poner todo esto en un archivo data_model.py separado tendría sentido, por lo que puedo hacer from mypackage.data_model import SomeData, SomeSubData
Si tiene una clase con mucho código, tal vez con algunas funciones que solo utiliza, sería una buena idea dividir esta clase y las funciones de ayuda en un archivo separado.
Debería estructurarlos para que lo haga from mypackage.database.schema import MyModel , no from mypackage.email.errors import MyDatabaseModel - si desde dónde está importando cosas desde sentido, y los archivos no tienen decenas de miles de líneas de longitud, Lo he organizado correctamente.
La documentación de los módulos de Python tiene información útil sobre la organización de paquetes.
Me encuentro dividiendo las cosas cuando me enojo con la gran cantidad de archivos y cuando la estructura deseable de la relación comienza a surgir de forma natural. A menudo estas dos etapas parecen coincidir.
Puede ser muy molesto si divide las cosas demasiado pronto, porque comienza a darse cuenta de que se requiere un ordenamiento de la estructura totalmente diferente.
Por otro lado, cuando un archivo .java o .py está llegando a más de 700 líneas, empiezo a molestarme constantemente al recordar dónde está "ese bit en particular".
Con Python / Jython, la dependencia circular de las declaraciones de importación también parece desempeñar un papel: si intenta dividir demasiados bloques de construcción básicos en archivos separados, esta "restricción" / "imperfección" del lenguaje parece obligarlo a agrupar cosas, tal vez de una manera bastante sensible.
En cuanto a la división en paquetes, no lo sé, pero diría que probablemente la misma regla de molestia y emergencia de una estructura feliz funciona en todos los niveles de modularidad.
Me gusta el modelo de Java por la siguiente razón. Colocar cada clase en un archivo individual promueve la reutilización al hacer que las clases sean más fáciles de ver cuando se navega por el código fuente. Si tiene un grupo de clases agrupadas en un solo archivo, puede que no sea obvio para otros desarrolladores que existen clases que se pueden reutilizar simplemente al navegar por la estructura de directorios del proyecto. Por lo tanto, si crees que tu clase posiblemente puede ser reutilizada, la pondría en su propio archivo.
Un archivo de Python se llama "módulo" y es una forma de organizar su software para que tenga "sentido". Otro es un directorio, llamado "paquete".
Un módulo es una cosa distinta que puede tener una o dos docenas de clases estrechamente relacionadas. El truco es que un módulo es algo que importará, y necesita que la importación sea perfectamente sensible para las personas que leerán, mantendrán y ampliarán su software.
La regla es esta: un módulo es la unidad de reutilización .
No puedes reutilizar fácilmente una sola clase. Debes poder reutilizar un módulo sin ninguna dificultad. Todo en su biblioteca (y todo lo que descarga y agrega) es un módulo o un paquete de módulos.
Por ejemplo, estás trabajando en algo que lee hojas de cálculo, hace algunos cálculos y carga los resultados en una base de datos. ¿Cómo quieres que sea tu programa principal?
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 )
Piense en la importación como la forma de organizar su código en conceptos o partes. Exactamente cuántas clases hay en cada importación no importa. Lo que importa es la organización general que está representando con sus declaraciones de import .
Yo diría que poner tantas clases como se puedan agrupar lógicamente en ese archivo sin que sea demasiado grande y complejo.