Escogiendo entre módulos y clases.

Question

En mi aplicación, tengo que mantener el estado de la aplicación global y los métodos globales de la aplicación, como los usuarios actualmente conectados, el número total de respuestas, crear un archivo de configuración de la aplicación, etc. Hay dos opciones:

1. Cree un archivo appstate.py separado con variables globales con funciones sobre ellas. Se ve bien al principio, pero parece que me falta algo en la claridad de mi código.

2. Cree una clase AppState con funciones de clase en un archivo appstate.py, todos los demás módulos se han definido por sus trabajos específicos. Esto se ve bien. Pero ahora tengo que escribir una línea más larga como appstate.AppState.get_user_list (). Además, los métodos no están tan relacionados entre sí. Puedo crear clases separadas, pero eso sería demasiadas clases.

EDITAR: Si uso clases, usaré métodos de clase. No creo que sea necesario crear una instancia de la clase a un objeto.

Answer 1

El segundo enfoque parece mejor. Usaría el primero solo para archivos de configuración o algo así.

De todos modos, para evitar el problema siempre podrías:

from myapp.appstate import AppState

De esa manera ya no tendrá que escribir la línea larga.

Answer 2

Suena como el enigma clásico :-).

En Python, no hay nada sucio o vergonzoso en elegir usar un módulo si ese es el mejor enfoque. Después de todo, los módulos, funciones y similares son, de hecho, ciudadanos de primera clase en el lenguaje, y ofrecen introspección y propiedades que muchos otros lenguajes de programación ofrecen solo por el uso de objetos.

En la forma en que describiste tus opciones, parece que no estás tan loco por un enfoque basado en clases en este caso.

No sé si has usado el marco de Django, pero si no, mira la documentación sobre cómo maneja la configuración. Estos son para toda la aplicación, están definidos en un módulo y están disponibles a nivel mundial. La forma en que analiza las opciones y las expone a nivel mundial es bastante elegante, y puede que este enfoque le resulte inspirador para sus necesidades.

Answer 3

El segundo enfoque solo es significativamente diferente del primer enfoque si tiene el estado de la aplicación almacenado en una instancia de AppState, en cuyo caso su queja no se aplica. Si solo estás almacenando cosas en una clase y estás usando métodos estáticos / de clase, tu clase no es diferente a un módulo, y sería más bien un pitón tenerlo como un módulo.

Answer 4

¿Por qué no ir con una instancia de esa clase? De esa forma, incluso podría tener 2 sesiones diferentes " " corriendo, dependiendo de qué instancia uses. Podría hacerlo más flexible. Tal vez agregue algún método get_appstate () al módulo para instanciar la clase una vez. Más adelante, si desea varias instancias, puede cambiar este método para eventualmente tomar un parámetro y usar algún diccionario, etc. para almacenar esas instancias.

También puede usar decoradores de propiedades por cierto para hacer las cosas más legibles y tener la flexibilidad de almacenarlo cómo y dónde lo almacena.

Estoy de acuerdo en que sería más pirónico utilizar el enfoque de módulo en lugar de los métodos de clase.

Por cierto, no soy tan fanático de tener las cosas disponibles a nivel mundial por parte de " magic " ;. Prefiero usar alguna llamada explícita para obtener esa información. Entonces sé de dónde vienen las cosas y cómo depurarlo cuando las cosas fallan.

Answer 5

Considera este ejemplo:

configuration
|
+-> graphics
|   |
|   +-> 3D
|   |
|   +-> 2D
|
+-> sound

La verdadera pregunta es: ¿cuál es la diferencia entre las clases y los módulos en esta jerarquía, ya que podría representarse por ambos medios?

Las clases representan tipos. Si implementas tu solución con clases en lugar de módulos, puedes verificar que un objeto gráfico sea del tipo correcto, pero escribir funciones gráficas genéricas.

Con las clases puedes generar valores parametrizados. Esto significa que es posible inicializar de forma diferente la clase sonidos con un constructor, pero es difícil inicializar un módulo con diferentes parámetros.

El punto es que realmente eres diferente del punto de vista de modelado.

Answer 6

Iría con la ruta de clases, ya que organizará mejor tu código. Recuerda que para facilitar la lectura puedes hacer esto:

from appstate import AppSate

Answer 7

Definitivamente optaría por la segunda opción: después de haber usado la primera, ahora estoy obligado a refactorizar, ya que mi aplicación evolucionó y tengo que admitir más construcciones modulares, por lo que ahora necesito manejar múltiples configuraciones simulativas '.

El segundo enfoque es, en mi opinión, más flexible y seguro para el futuro. Para evitar las líneas de código más largas, puede utilizar desde AppState import AppState en lugar de solo import appstate .