2009-07-07 17 views
34

Duplicar posibles:
How many Python classes should I put in one file?¿Se recomiendan múltiples clases en un único archivo?

Viniendo de experiencia en C++ me he acostumbrado a organizar mis clases de tal manera que, en su mayor parte, hay una relación 1: 1 entre las clases y archivos . Al hacer que un solo archivo contenga una única clase, encuentro que el código es más navegable. Al presentarme a Python, estoy encontrando muchos ejemplos donde un solo archivo contiene múltiples clases. ¿Es esa la forma recomendada de hacer las cosas en Python? Si es así, ¿por qué?

¿Me falta esta convención en el PEP8?

+2

Duplicado: http://stackoverflow.com/questions/106896/how-many-python-classes-should-i-put-in-one-file/107836#107836 –

Respuesta

41

Estas son algunas de las razones posibles:

  1. Python no es exclusivamente basada en la clase - la unidad natural de descomposición código en Python es el módulo. Los módulos tienen la misma probabilidad de contener funciones (que son objetos de primera clase en Python) como clases. En Java, la unidad de descomposición es la clase. Por lo tanto, Python tiene un módulo = un archivo, y Java tiene una clase (pública) = un archivo.
  2. Python es mucho más expresivo que Java, y si se restringe a una clase por archivo (lo que Python no evita que haga) terminará con muchos archivos muy pequeños, más para realizar un seguimiento con muy poco beneficio.

Un ejemplo de funcionalidad aproximadamente equivalente: log4j de Java => un par de docenas de archivos, ~ 8000 SLOC. Registro de Python => 3 archivos, ~ 2800 SLOC.

5

En python, la clase también se puede usar para tareas pequeñas (solo para agrupar, etc.). mantener una relación 1: 1 daría como resultado tener demasiados archivos con funcionalidad pequeña o pequeña.

14

Hay un mantra, "plano es mejor que anidado", que generalmente desalienta el uso excesivo de la jerarquía. No estoy seguro de que existan reglas rígidas sobre cuándo se quiere crear un nuevo módulo; la mayoría de las personas simplemente usan su discreción para agrupar funcionalidades lógicamente relacionadas (clases y funciones que pertenecen a un dominio problemático en particular) .

Buena thread from the Python mailing list, y una cita por Fredrik Lundh:

aún más importante es que en Python, que no utilizan las clases de every- cosa; si necesita fábricas, singletons, múltiples formas de crear objetos , ayudantes polimórficos, etc., usted usa funciones simples, no clases o métodos estáticos .

una vez que haya recibido el "Todo" clases, módulos utilizar para organizar cosas de una manera que tenga sentido para el código que utiliza sus componentes.
hacen que las declaraciones de importación se vean bien.

+1

Me encantó la explicación del uso excesivo de la parte de la jerarquía. A veces es extremadamente difícil de entender el código cuando hay un uso excesivo de la jerarquía. Especialmente cuando no está bien documentado, incluso un código 'hola mundo' se convierte en un dolor de cabeza – MuhsinFatih

3

No existe una convención específica para esto: haga lo que haga que su código sea más legible y fácil de mantener.

2

el libro Expert Python Programming tiene algo relacionado discusión
Capítulo 4: La elección de buenos nombres: "Construyendo el árbol de espacio de nombres" y "División del Código"
Mi línea de resumen crudo: recoger algo de clase relacionada a un módulo (archivo de origen) y recopilar algún módulo relacionado a un paquete, es útil para mantener el código.

1

Un buen ejemplo de no tener archivos separados para cada clase podría ser el archivo models.py dentro de una aplicación django. Cada aplicación django puede tener un puñado de clases que están relacionadas con esa aplicación, y ponerlas en archivos individuales simplemente hace más trabajo.

De manera similar, tener cada vista en un archivo diferente nuevamente es probable que sea contraproducente.

Cuestiones relacionadas