¿Cómo organizar mi código de Python en múltiples clases?

Question

Me dijeron recientemente que debería mantener mi código en archivos separados; como main.py, engine.py, settings.py y así sucesivamente. Aunque esto seguramente tiene beneficios, como una administración más sencilla, escalabilidad y otros, para mí parece que tiene demasiados inconvenientes ...

Por ejemplo, si tengo un script llamado settings.py, donde algunas cosas como tamaños de pantalla Se definen los objetos, la velocidad de la simulación y el color de varios objetos, ¿qué debo hacer si esas variables son necesarias tanto en mi script engine.py como en mi script main.py? ¿Lo importo dos veces, en ambos guiones? Parece bastante desordenado. ¿Qué pasa si algunas de mis clases, que están en el script engine.py, requieren el código de main.py?

Te voy a enseñar la situación exacta ...

Mi script main.py importa Pygame en sí mismo, lo inicializa, y así sucesivamente. Solía ​​tener una clase que representaba un objeto en pantalla, y esa clase tenía un método draw, que acaba de llamar una función de dibujo Pygame. Ahora, cuando puse la clase dentro de mi script engine.py, las cosas ya no funcionan, ¡porque Pygame no existe allí! Terminé importando tanto settings.py como Pygame en el engine.py, y luego importando el motor en main.py, pero luego es más como un inicializador que como un motor ... ¿Hay alguna manera de tratar con cosas como estas, como las líneas de guía generales?

Answer 1

Estas son las directrices de PEP oficiales para la importación: http://www.python.org/dev/peps/pep-0008/#imports

También consulte esta pregunta StackOverflow: What are good rules of thumb for Python imports?

puede importar una variable de más de una clase sin un problema, pero usted debe tratar de estructurar su código para que las cosas no se importen de forma circular. Circular import dependency in Python

Answer 2

Deberías echarle un vistazo a este modelo, que podría ayudarte a entender las cosas. Creo que este es el que serían más adecuadas con lo que quiere hacer

Model-View-Controller

Algunos más doc aquí: http://www.wkoorts.com/wkblog/2007/12/23/mvc-design-patterns-with-python-links/

En este caso, las importaciones deben parecer bastante lógico y necesario . Y agregaría que es más o menos lo que ya hace con sus 3 archivos.

Answer 3

No es una respuesta, pero:

settings.py realmente debería estar settings.ini, y es preferible hacerlo mediante ConfigParser. Lea el archivo de configuración una vez y comparta el resultado ConfigParser.RawConfigParser entre los módulos.

Answer 4

Es una práctica común en otros lenguajes (especialmente Java, donde es prácticamente obligado por el compilador) tener un archivo por clase.

En cuanto a las dependencias entre archivos que menciona, debería considerar evitar las variables globales.

Aquí hay otra pregunta relacionada que responde mejor a su pregunta.

How many Python classes should I put in one file?

Answer 5

Puede importar símbolos de settings.py en cualquiera de los módulos que se necesitan. Ese es el concepto. Un problema real es cuando tienes importaciones circulares. p.ej. ¿Qué sucede si tiene algunos símbolos dentro de engine.py que se necesitan en main.py y viceversa? En esa situación, un patrón común es romper estas dependencias en un tercer módulo, donde podrían importarse main.py y engine.py, sin ningún problema.

Answer 6

Importar un módulo en otros muchos módulos no es complicado. Es mucho más limpio que un módulo con muchos miles de líneas de código.

Es cierto que las importaciones circular son problemáticas. Pero su situación no parece que vaya a haber un problema circular de importación. Usted dice que "ahora, cuando puse la clase dentro de mi script engine.py, las cosas ya no funcionan, porque Pygame no existe allí. Terminé importando tanto settings.py como Pygame en el motor.py, y luego importando el motor en main.py ".

¿Por qué no puede simplemente poner la clase en engine.py y luego importarla en main.py? Una forma muy simple de hacer esto sería para pasar una devolución de llamada a su clase:

# engine.py 
... 
class ClassWithDraw(Subclass): 
    def __init__(self, draw_callback): 
     ... 
     self._draw_func = draw_callback 
     ... 
    def draw(self): 
     self._draw_func() 

# main.py 

from engine import ClassWithDraw 
drawer = ClassWithDraw(drawfunc) 

Lo bueno de este enfoque es que el objeto es realmente sólo es responsable de una cosa: su propio estado. De hecho, podría tener más sentido para este objeto no tener un método draw; o podría tener un draw_hook que se llamaría para obtener datos dibujables cuando sea necesario, y otra función de extracción externa podría llamarlo.

Otro enfoque más sería tener un módulo completamente separado para Pygame. No sé mucho sobre Pygame, por lo que es posible que esto no funcione, pero supongamos que tienes un módulo que maneja la inicialización y el estado de Pygame. Puede inicializarlo una vez, en main, e importarlo donde desee.