6
votes

Quelque chose ne va pas avec un très grand __init__?

J'écris un programme Python avec une interface graphique construite avec le module Tkinter. J'utilise une classe pour définir l'interface graphique car il est facile de passer des commandes aux boutons et rend le tout un peu plus facile à comprendre.

L'initialisation réelle de mon interface graphique prend environ 150 lignes de code. Pour rendre cela plus facile à comprendre, j'ai écrit la fonction __ init __ comme: xxx

_init_menu () , _Init_connectbar () , et ainsi de suite faire tout le travail d'initialisation. Cela facilite mon code de suivre et empêche __ init __ de devenir trop gros.

Cependant, cela crée des problèmes d'étendue. Puisqu'un widget d'entrée que j'ai défini dans _init_connecectbar () est dans la fonction de fonction et n'est pas un attribut de classe, je ne peux pas y parvenir à d'autres méthodes de la classe.

Je peux faire que ces problèmes disparaissent en faisant la majeure partie de l'initialisation dans __ init __ , mais je perdrai l'abstraction que j'ai eu avec ma première méthode.

devrais-je développer __ init __ ou trouver un autre moyen d'apporter les widgets en périmètre de classe?


0 commentaires

4 Réponses :


1
votes

Vous devez regarder dans le Modèle de constructeur pour ce genre de choses. Si votre interface graphique est complexe, il y aura une certaine complexité pour la décrire. Que ce soit une fonction complexe ou une description complexe dans certains fichiers se résume à la même chose. Vous pouvez simplement essayer de le rendre lisible et de maintenir le plus possible possible et, dans mon expérience, le modèle de constructeur aide vraiment ici.


0 commentaires

2
votes

À mon avis, vous devez stocker les widgets sous forme de variables d'instance afin que vous puissiez les faire référence à partir de n'importe quelle méthode. Comme dans la plupart des langages de programmation, la lisibilité diminue lorsque les fonctions deviennent trop volumineuses, alors votre approche de scinder le code d'initialisation est une bonne idée.

Lorsque la classe elle-même pousse trop volumineuse pour un fichier source, vous pouvez également séparer la classe. en utilisant des classes de mélange (semblables à des classes partielles en C #). p>

Par exemple: P>

class MainGuiClass(GuiMixin_FunctionalityA, GuiMixin_FunctionalityB):
    def __init__(self):
        GuiMixin_FunctionalityA.__init__(self)
        GuiMixin_FunctionalityB.__init__(self)


2 commentaires

Bonne réponse, mais vous êtes un peu trop prudent. La lisibilité diminue pour les grandes fonctions dans toutes les langages de programmation .


Wow. Aurait dû voir qu'on venant :)



5
votes

Stockez certaines de ces références de widget par exemple des variables ou renvoyez-les (un esprit minimal vous; vous souhaitez réduire le couplage) et stockez-les dans des variables locales dans __ init __ avant de transmettre les pertinents arguments à vos aides de construction ultérieurs. Ce dernier est plus propre, mais nécessite que les choses soient suffisamment découplées pour que vous puissiez créer une commande qui le rend possible.


2 commentaires

Merci, c'est ce que je devrais vraiment faire. Je suppose que je vais simplement avoir chaque _init_something renvoie les widgets qu'il initialise.


@Rafe: juste les widgets "intéressants". Les Guis ont souvent d'autres choses comme des étiquettes et des cadres qui ne sont pas intéressants; Ils sont comme l'ensemble que les widgets intéressants (entrées, boîtes de répression, toiles, etc.) jouent leur rôle. (Bien sûr, parfois, les entrées ne sont pas vraiment intéressantes et les étiquettes sont, mais cela dépend des détails de l'interface graphique que vous construisez ...)



2
votes

Pourquoi ne faites-vous pas vos widgets que vous devez faire référence à des variables d'instance. C'est ce que je fais de l'usage et semble être une approche assez courante.

E.g. P>

self.some_widget


2 commentaires

Je suppose que je puisse définir chaque widget dans __ init __ , puis exécutez des méthodes pour effectuer la configuration et l'emballage réels de chaque widget.


Ce n'est pas exactement ce que je suggérais. Bien que je dispose généralement d'une méthode distincte à la mise en page, vous pouvez toujours définir vos widgets dans vos méthodes __ init__widget () , mais la création de vos variables d'instance Widgets signifie que vous pouvez y accéder d'autre.