Premièrement, j'aimerais souligner que je connais des concepts OOP et comprendre les différences entre les dictionnaires et les classes. Ma question concerne ce qui fait sens de la conception de sens dans ce cas:
Je concevons une webapp à Python et je dois représenter quelque chose comme un objet de livre. Les livres ont des chapitres et des chapitres ont des titres et un contenu. Pour la simplicité, disons que le contenu est un texte brut.
Ma question est que devrais-je faire des classes de livre et de chapitre ou de dictionnaires? Je sais que cela chercherait Néater pour utiliser Book.Chapter au lieu de livre ['chapitre'], et si je finis par avoir des méthodes à l'avenir, cela pourrait être logique de les mettre dans la classe de livre. Cependant, j'aimerais savoir s'il y a des frais généraux pour utiliser des classes au lieu de stocker les informations dans des dictionnaires?
Si je ne veux pas instancier d'un objet de livre à partir d'une base de données à chaque fois et stockez-la comme un cornichon, je devrais vous inquiéter de l'incompatibilité avec les objets du livre passé si j'ajoute / supprimer des membres de données d'une classe.i Sensez que ce serait plus facile de faire face à ce problème dans les dictionnaires. Tous les pointeurs sur la question de savoir si / quand il est logique d'utiliser des dictionnaires au lieu de classes?
6 Réponses :
Des objets ont été créés à l'origine pour regrouper des données avec des fonctionnalités. Si vous souhaitez simplement stocker des données, utilisez des dictionnaires. Si vous souhaitez inclure des méthodes de manipulation des données, utilisez des objets.
Je pense que la première phrase est un mythe.
@Svante, si c'est un mythe, alors quelle est la vérité?
Non, je l'ai lu dans un livre C qui a tracé l'historique des types de données.
@Svante: En désaccord: le modèle d'objet est conçu pour couper des attributs et un comportement. EN.Wikipedia.org/wiki/...
Ok, je suppose que j'ai pris le mot "paquet" trop sérieux. "Couple" est beaucoup mieux.
Quelques réflexions:
Si vous commencez par un dictionnaire, vous pouvez toujours passer à une classe personnalisée ultérieurement qui implémente le protocole de mappage (ou les sous-classes dict). Donc, c'est probablement un bon point de départ.
Vous pouvez définir des objets Python personnalisés à utiliser Si vous utilisez un objet Python personnalisé, il sera plus facile de le remplacer à l'avenir par un objet écrit dans C. (Je ne l'ai jamais essayé, mais je m'attendrais à ce que la sous-classement dict de c une proposition délicate.)
__ Slots __ , qui sera plus rapide et plus efficace si vous avez un grand nombre d'objets.
Si vous allez avec des objets, je ne stockerais pas les données marinées dans la base de données simplement pour les raisons que vous avez données. Il serait considérablement pire si vous avez subi un changement de langue ou similaire.
FWIW, je commencerais par un dictionnaire. Si les choses deviennent compliquées ou que de nouvelles fonctionnalités sont nécessaires, faites-en un objet.
Les dicts crus sont beaucoup plus faciles à vider à Json, échangent avec d'autres programmes etc. Ils ne nécessitent aucune définition de classe personnalisée (autre qu'une description de la convention de nidification, qui est évidente).
Ceci est hautement il est peu probable qu'il s'agisse du goulot d'étranglement de votre application, vous craignez donc que la performance est probablement une perte de temps. Cependant, si c'est le goulot d'étranglement ou que vous avez un peu de temps sur vos mains, examinez-vous à l'aide d'un nomméTuple . Il combine l'imputabilité et la faible teneur en mémoire d'un tuple avec la nice syntaxe des attributs de classe.
+1 pour mentionner NamedTuple. Si vous utilisez Python> = 2,6, c'est certainement un bon choix pour examiner.
+1: Ce n'est pas "probablement une perte de temps". C'est une perte de temps. Tous les cadres Web utilisent des cours. Il suffit d'utiliser des classes.
S. Lott, qu'est-ce que "tous les cadres Web utilisent des classes" a à voir avec cela? Vous suggérez-vous que les cadres Web sont des guides pour les meilleures performances de Metal-Metal? Ou suggérez-vous, ils sont "assez rapides", même avec le (très petit) surcharge de classes.
Vous résumez très bien les compromis. Il semble que beaucoup de gens s'inquiètent beaucoup trop tôt sur la performance. Plutôt que de répéter les conseils standard sur le sujet, je vous suggère de rechercher sur le Web pour "Optimisation prématurée de Knuth". Le fait est que pour les objets de structure connus vous serez très heureux d'utiliser des objets à base de classe que les dicts.
Encore une fois, votre désir de ne pas instantiaire d'objets à chaque fois que leurs données (instance) sont lues sous la forme de la base de données représente une mise au point légèrement malsaine sur les mauvaises parties du design de votre programme. Créer une instance d'une de vos classes à partir d'attributs de données prend très peu de temps et que la commodité de pouvoir ajouter un comportement à travers des méthodes vaut bien la légère complexité supplémentaire.
Utiliser un dict avec des sous-domestibles constants pour référencer les éléments d'un objet de données me semble tort. Vous éliminez efficacement le mécanisme d'espace de noms de Python et créez de nombreux constantes de cordes inutiles (qui ne seront pas nécessairement consolidées par l'interprète). Si vous êtes vraiment intéressé à la vitesse, alors pourquoi ne pas utiliser une liste, avec des constantes symboliques pour les noms de champs? Réponse: Parce qu'il serait erroné de contourner votre code de cette manière pour une augmentation potentiellement illusoire de la vitesse d'exécution que dans 99% de tous les cas (une figure que je viens de cueillir de mon cul) ne sera pas remarquée parce que le L'application n'est pas liée à la CPU.
Écrivez votre programme la façon la plus simple que vous savez comment. Si cela fonctionne et fonctionne assez rapidement, passez à la tâche suivante.