réflexions sur l'organisation du code

Bonjour,

Autant, j'arrive a faire ce que je veux en terme de fonctionnalité, autant d'un point de vue organisation du code interface en partie et passage de paramètre je ne me sens pas au top.

Concrètement, j'ai créé plusieurs objets pour

• gérer les données persistantes
• gérer les configurations utilisateur
• gérer les tâches à réaliser
• définir l'interface graphique (crée avec Qt designer)

Il manque maintenant le ciment pour lancer les opérations depuis l'interface graphique et je recherche une solution élégante transmettre des informations entre tous les objets notamment l'interface graphique.
J'ai envisagé d'utiliser des variables globales mais ce n'est pas élégant
de créer une classe application qui hérite de toute les autres (pas sur que ça marche)
d'initialiser les objets fonctionnels à l'intérieur de la partie graphique mais je perd la séparation entre interface et process
:mur:

Et vous comment faites-vous ?

Bonjour

Citation:

---

Envoyé par johnsdoeuf

Autant, j'arrive a faire ce que je veux en terme de fonctionnalité, autant d'un point de vue organisation du code interface en partie et passage de paramètre je ne me sens pas au top.

Concrètement, j'ai créé plusieurs objets pour

• gérer les données persistantes
• gérer les configurations utilisateur
• gérer les tâches à réaliser
• définir l'interface graphique (crée avec Qt designer)

---

C'est pas mal. Ce que tu as fait de façon empirique est connu sous le nom de MVC (Modèle/Vue/contrôleur). Le modèle c'est la façon dont sont stockées les données (fichier, bdd, etc). La vue c'est la façon de saisir et d'afficher les données (print/input, Qt, tcl/tk, etc) et le contrôleur c'est la façon donc les données sont traitées pour produire un résultat.

Citation:

---

Envoyé par johnsdoeuf

Il manque maintenant le ciment pour lancer les opérations depuis l'interface graphique et je recherche une solution élégante transmettre des informations entre tous les objets notamment l'interface graphique.

---

Oui, j'ai eu le même souci.
Ma solution :

• dans le programme principal je crée tous mes objets (l'objet pour gérer l'environnement, l'objet pour gérer la bdd, l'objet pour gérer la config, etc) que je stocke dans un dico
• je passe le dico à mon QtAppli (un objet perso qui hérite d'un QApplication) qui ainsi a accès à tous ces autres objets. Et lui il peut ensuite passer ce dico à n'importe quel sous-objet qui en a besoin

Exemple de programme principal

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53

#!/usr/bin/env python3 # coding: utf-8   # Modules Python import os # Gestion os   # Modules locaux from libIHM import * # IHM de l'application from libBdd import * # Bdd de l'application from libOutils import * # Outils de l'application   # Fonction principale def Appli( *, # Imposition passage par nom args, # Arguments du programme ):   # Récupération modules application envp=cEnv(argv=args) bdd=cBdd( dbname=cEnv.dbname, log=os.path.join( envp.wdir, "historique", "histo_log.sql", ) ) crypto=cCrypto(lenKey=0) licence=cLicence()   # Lancement de l'IHM avec les éléments du logiciel status=QtAppli( envp=envp, crypto=crypto, licence=licence, bdd=bdd, ).run()   # Fermeture modules application envp.close() bdd.close() licence.close() crypto.close() return status # Appli()   # Si le module est lançé en tant que programme if __name__ == "__main__": import sys   # Lancement fonction principale sys.exit(Appli(args=sys.argv)) # if

---

Et le début de mon QtAppli

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45

# Objet pour gérer l'ordonnanceur IHM class QtAppli( QApplication): # Objet hérité "Objet pour gérer l'ordonnanceur IHM"   # Constructeur def __init__( self, # Instance objet *args, # Liste arguments **kwargs, # Association arguments ):   # Environnement ihm self._ihm={ "appli" : self, "mainWid" : None, "envp" : kwargs.pop("envp"), "crypto" : kwargs.pop("crypto"), "licence" : kwargs.pop("licence"), "bdd" : kwargs.pop("bdd"), }   # Appel constructeur de l'objet hérité super().__init__(*args, **kwargs)   # Widget principale self._ihm["mainWid"]=QtMainWindow(self._ihm)   ...   # Affichage et lancement application def run( self, # Instance objet ):   # Réinitialisation appli self.clear() self.verrou()   # Affichage fenêtre self._ihm["mainWid"].show()   # Lancement application return self.exec_() # run()

---

De là, mon objet Qt possède un dictionnaire nommé "_ihm" qui fait le ciment. Si ensuite un sous-objet Qt a besoin de ces infos, alors je lui passe le dico "_ihm" (comme dans la dernière ligne de cet exemple où j'ai un objet "QtMainWindow" qui hérite d'un QMainWindow

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

# Objet pour gérer la fenêtre principale class QtMainWindow( QMainWindow): # Objet hérité "Objet pour gérer la fenêtre principale"   # Constructeur def __init__( self, # Instance objet ihm, # Environnement ihm *args, # Liste arguments **kwargs, # Association arguments ):   # Récupération environnement ihm self._ihm=dict(ihm) self._ihm["self"]=self self._ihm["mainWid"]=self   # Appel constructeur objet hérité super().__init__(*args, **kwargs) ...

---

Et j'ai mon ciment.

Salut,

Citation:

---

Envoyé par johnsdoeuf

Et vous comment faites-vous ?

---

Ce n'est jamais simple... mais essayez de penser "composants" qui gèrent les différents sous ensemble puis en terme d'interface (ou de services à rendre aux autres composants)....
Ce qui doit vous amener à découper le problèmes en classes (d'interfaces).

Après côté échange d'informations/données, vous pouvez déjà utilisez la mécanique signals/slots de Qt qui est assez flexible.

Ce qui est sûr, c'est que variables globales ou tout hériter dans une seule classe (ce qui revient presque au même) fonctionne mais on l'évite parce que difficile à maintenir et à faire évoluer. Hélas, l'alternative c'est la POO, et ce n'est pas si facile à apprendre (sauf pour faire des trucs basiques).

- W

Merci pour vos réponses

Ser@r, ta solution est séduisante

ton exemple devrais bien m'aider pour y parvenir :)

Merci encore

Citation:

---

Envoyé par Sve@r

Et j'ai mon ciment.

---

Si le mapping ne bouge pas et autant avoir un module globals (un dictionnaire) plutôt que N copies où il faudra peut être s'assurer (par des règles) qu'elles restent cohérentes.

La solution POO est soit d'utiliser un module comme singleton (import du module s'initialise une fois mais ses fonctions/classes sont accessibles) soit réaliser des singletons avec des "class".

- W