choix entre modules et classes

Question

Dans mon application, je dois gérer certaines méthodes globales d'état de l'application et globales telles que les utilisateurs actuellement connectés, le nombre total de réponses, créer un fichier de configuration d'application, etc. Il existe deux options:

1. Créez un fichier appstate.py séparé avec des variables globales sur lesquelles des fonctions sont placées. Cela semble bien au début, mais il me manque quelque chose dans la clarté de mon code.

2. Créez une classe AppState avec des fonctions de classe dans un fichier appstate.py. Tous les autres modules ont été définis par leurs travaux spécifiques. Cela a l'air bien. Mais maintenant, je dois écrire une ligne plus longue comme appstate.AppState.get_user_list (). De plus, les méthodes ne sont pas tellement liées les unes aux autres. Je peux créer des classes séparées, mais cela ferait trop de classes.

EDIT: Si j'utilise des classes, j'utiliserai des méthodes de classe. Je ne pense pas qu'il soit nécessaire d'instancier la classe à un objet.

Answer 1

La deuxième approche semble meilleure. Je n'utiliserais le premier que pour les fichiers de configuration ou quelque chose du genre.

Quoi qu'il en soit, pour éviter le problème, vous pouvez toujours:

from myapp.appstate import AppState

Ainsi, vous n’aurez plus à écrire la longue ligne.

Answer 2

Cela ressemble au casse-tête classique: -).

En Python, il n’ya rien de sale ou de honteux à choisir d’utiliser un module si c’est la meilleure approche. Après tout, les modules, les fonctions, etc., sont en réalité des citoyens de premier ordre dans le langage et offrent une introspection et des propriétés que de nombreux autres langages de programmation n'offrent que par l'utilisation d'objets.

La façon dont vous avez décrit vos options vous donne l’impression que vous n’êtes pas trop fous d’une approche fondée sur les classes dans ce cas.

Je ne sais pas si vous avez utilisé le framework Django, mais sinon, consultez la documentation sur la façon dont il gère les paramètres. Celles-ci sont définies à l’échelle de l’application, définies dans un module et disponibles au niveau mondial. La manière dont elle analyse les options et les expose globalement est assez élégante, et une telle approche peut répondre à vos besoins.

Answer 3

La seconde approche ne diffère sensiblement de la première que si l'état de l'application est stocké dans une instance d'AppState, auquel cas votre plainte ne s'applique pas. Si vous ne faites que stocker des éléments dans une classe et que vous utilisez des méthodes static / class, votre classe n’est pas différente de celle d’un module et il serait pythonique de l’avoir plutôt comme module.

Answer 4

Pourquoi ne pas utiliser une instance de cette classe? De cette façon, vous pourrez même avoir plus tard deux sessions différentes. en cours d'exécution, selon l'instance que vous utilisez. Cela pourrait le rendre plus flexible. Peut-être ajouter une méthode get_appstate () au module afin qu’il instancie la classe une fois. Par la suite, si vous souhaitez plusieurs instances, vous pouvez modifier cette méthode pour éventuellement prendre un paramètre et utiliser un dictionnaire, etc. pour stocker ces instances.

Vous pouvez également utiliser les décorateurs de propriétés pour rendre les choses plus lisibles et avoir la possibilité de les stocker comme et où vous le souhaitez.

Je conviens qu'il serait plus pythonique d'utiliser l'approche de module au lieu de méthodes de classe.

BTW, je ne suis pas un grand fan des choses "magiques" disponibles dans le monde entier. Je préfère utiliser un appel explicite pour obtenir cette information. Ensuite, je sais d'où viennent les choses et comment les résoudre en cas d'échec.

Answer 5

Considérez cet exemple:

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

La vraie question est la suivante: quelle est la différence entre les classes et les modules de cette hiérarchie, puisqu'elle pourrait être représentée par les deux moyens?

Les classes représentent des types. Si vous implémentez votre solution avec des classes au lieu de modules, vous pouvez vérifier le type approprié d’un objet graphique, mais écrire des fonctions graphiques génériques.

Avec les classes, vous pouvez générer des valeurs paramétrées. Cela signifie qu'il est possible d'initialiser différemment la classe sons avec un constructeur, mais il est difficile d'initialiser un module avec des paramètres différents.

Le fait est que vous avez vraiment quelque chose de différent du point de vue de la modélisation.

Answer 6

Je choisirais la route des classes car elle organisera mieux votre code. Rappelez-vous que par souci de lisibilité, vous pouvez le faire:

from appstate import AppSate

Answer 7

Je choisirais certainement la deuxième option: après avoir déjà utilisé la première, je suis maintenant obligé de refactoriser, car mon application a évolué et doit prendre en charge des constructions plus modulaires. J'ai donc maintenant besoin de gérer plusieurs configurations simultanées. '.

La deuxième approche est, IMO, plus flexible et plus durable. Pour éviter les lignes de code plus longues, vous pouvez utiliser dans AppState import AppState au lieu de import appstate .