Discussion :

[alpha.centauri]

hello,

j'apprends python "sur le tas" et, vu la masse d'info disponible, pas toujours facile de s'y retrouver...

je me suis lancé avec tkinter, j'ai défini ma fenêtre IHM dans une classe, jusque là, tout va bien.

ma question à laquelle je n'ai pas encore trouvé réponse : où dois-je mettre les traitements ? dans la classe qui définit la fenêtre, ou ailleurs ?

i.e. : l'appui sur un bouton de la fenêtre déclenche une FFT; je mets le code de la FFT dans un def de la classe d'initialisation de la fenêtre, ou ailleurs ?

dans la classe de la fenêtre, ça marche ; mais je me demande si c'est la bonne façon de faire.

si quelqu'un pouvait m'indiquer un tuto ou on traite ce genre de chose... (je n'ai peut-être pas bien vu, mais je n'ai pas trouvé dans les tutos du site)

[Sve@r]

Bonjour

ma question à laquelle je n'ai pas encore trouvé réponse : où dois-je mettre les traitements ? dans la classe qui définit la fenêtre, ou ailleurs ?

Bonne question. Pour trouver la réponse, il faut que tu penses à "comment mon code va-t-il évoluer dans le futur". Vas-tu garder Tk ? Vas-tu passer à autre chose ?

Généralement la réponse est dans le MVC (Modèle, Vue, Controleur). Une technique de programmation consistant à séparer "qui fait quoi".

Le Modèle, c'est tout ce qui est "stockage d'informations". Ca peut être dans des fichiers texte, en ram, en bdd, etc.
La Vue c'est tout ce qui est "saisie/affichage". Via des saisies mode texte, des fenêtres Tk, Qt, gtk, etc.
Le Controleur c'est tout ce qui est "calcul de résultat". Ca peut être fait par Python, par des langages dédiés aux calculs scientifiques, etc.

En séparant ces entités dans des fonctions distinctes, c'est plus facile ensuite quand tu veux modifier une techno par une autre. Le Modèle était dans des fichiers, il passe en bdd, tu ne changes que les interfaces d'enregistrement. Hier tu étais avec Tk, demain tu veux utiliser Qt, tu recréer une nouvelle IHM et tu la relies à ce qui existe déjà pour la récupération des infos stockées et le calcul. Et etc.

[alpha.centauri]

instinctivement, c'est bien ce que j'aurais dit ; séparer ihm et traitement...

là où j'ai un souci, c'est cette histoire de classe, je lis un peu partout que la classe pour la fenêtre IHM, c'est bien :-) c'est pourquoi je suis parti là-dessus.

par contre, si je sors les traitements de la classe pour les mettre dans le programme principal, je ne vois pas trop comment on fait communiquer ces traitements et la classe de la fenêtre...


si ça se trouve, l'utilisation de classes est peut-être un peu trop high level pour moi, ce serait sans-doute plus efficace de rester dans une programmation python à la papa... ;-)

[Sve@r]

là où j'ai un souci, c'est cette histoire de classe, je lis un peu partout que la classe pour la fenêtre IHM, c'est bien :-) c'est pourquoi je suis parti là-dessus.

C'est exact. Avoir une fenêtre de base qui fait saisir un truc c'est bien, mais avoir ta propre fenêtre qui hérite de la fenêtre de base et dans laquelle tu as des attributs persos pour traiter ce qui a été saisi c'est encore mieux.

par contre, si je sors les traitements de la classe pour les mettre dans le programme principal, je ne vois pas trop comment on fait communiquer ces traitements et la classe de la fenêtre...

Prenons un exemple simple: tu fais saisir un chiffre, puis tu affiches le chiffre au carré

Code Python :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
class Vue:
	def __init__(self):
		pass		# Peut-être plus tard
	def saisie(self):
		r=int(input("Entrez un nombre :"))
		print(r * r)
	# saisie()
# class Vue
 
ihm=Vue()
ihm.saisie()

Là, le traitement est dans la vue. C'est pas interdit, c'est pas mauvais, ça fonctionnera pendant des millénaires. Le seul truc c'est que si demain la vue change, il te faudra la réécrire et réécrire le traitement.

Second essai: 2 objets, le premier dédié à la vue, le second dédié au traitement

Code python :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
class Vue:
	def __init__(self, ctrl):
		self.__ctrl=ctrl
	def saisie(self):
		r=int(input("Entrez un nombre :"))
		print(self.__ctrl.traitement(r))
	# saisie()
# class Vue
 
class Controle:
	def __init__(self):
		pass		# Peut-être plus tard
	def traitement(self, n):
		return n*n
# class Controle
 
ctrl=Controle()
ihm=Vue(ctrl)
ihm.saisie()

Là, par exemple, la communication se fait parce que la vue embarque avec elle un objet permettant d'accéder au traitement. Ca fonctionne mais quelque part ça semble un peu compliqué (en réalité la méthode "traitement" ne dépendant pas vraiment d'une instance X ou Y devrait être statique ce qui simplifierait son appel mais je n'ai pas voulu trop en rajouter)

3° exemple: un module dédié au traitement
Fichier "ctrl.py"

Code python :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
def traitement(n):
		return n*n

Fichier "vue.py"

Code python :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
import ctrl
class Vue:
	def __init__(self):
		pass
	def saisie(self):
		r=int(input("Entrez un nombre :"))
		print(ctrl.traitement(r))
	# saisie()
# class Vue

Programme principal

Code python :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
import vue
 
ihm=vue.Vue()
ihm.saisie()

Comme tu vois, les solutions sont multiples pour arriver au résultat. Le reste n'est qu'une question de feeling. Quelque part tu "sens" ce qui conviendra le mieux. Parfois tu te trompes, ben c'est comme tout, tu peux aussi revenir en arrière et changer certains fondements.

si ça se trouve, l'utilisation de classes est peut-être un peu trop high level pour moi, ce serait sans-doute plus efficace de rester dans une programmation python à la papa... ;-)

Pas du tout. Une classe c'est juste un regroupement de caractéristiques appelés "attributs", associés à des traitements de ces attributs appelés "méthodes". Une fois qu'on y est habitué ça va très vite. Simplement les classes ça reste des outils donc comme tels ils peuvent être plus ou moins adaptés à la solution envisagée. Ainsi dans mon second exemple, la classe "Controle()" n'avait pas vraiment de plus-value et a disparu dans le 3° exemple au profit d'une fonction plus simple à appeler (retour en arrière et changement de certains fondements).

[alpha.centauri]

ah ben voilà, comme ça, c'est clair... :-)

la solution 2 me plait bien; je pense avoir saisi le concept, je n'ai plusqu'à essayer de l'appliquer à mon projet.

merci beaucoup...

[wiztricks]

Salut,

si quelqu'un pouvait m'indiquer un tuto ou on traite ce genre de chose... (je n'ai peut-être pas bien vu, mais je n'ai pas trouvé dans les tutos du site)

tkinter n'a rien de spécifique à la programmation d'une interface graphique.

Après la distribution des rôles entre l'interface utilisateur (affichage et dialogues) et les traitements est racontée par différents patterns de conception. MVC est populaire mais il y a des tas de variantes mentionnées dans la page wikipedia.

ma question à laquelle je n'ai pas encore trouvé réponse : où dois-je mettre les traitements ? dans la classe qui définit la fenêtre, ou ailleurs ?

La réponse est "ailleurs"... Et la difficulté est d'arriver à visualiser ce que çà veut dire dans l'organisation de votre code.
Le plus simple est de créer 2 applications fonctionnellement identiques: une avec une interface console et l'autre avec une interface graphique.
Les traitements seront les mêmes et indépendants de l'interface utilisateur.
Et voilà comment est défini le périmètre du Model.

Pour le reste, vous avez de la littérature et des tas de tutos.

- W

[alpha.centauri]

Pour le reste, vous avez de la littérature et des tas de tutos.

- W

c'est bien le pb, j'ai déjà bouffé un paquet de tutos qui m'ont permis d'arriver à définir ma fenêtre dans une classe, mais je n'en ai pas encore trouvé qui montre clairement comment on communique entre la classe de la fenêtre et le reste du monde.

si quelqu'un pouvait m'en indiquer un qui soit à la portée d'un simple amateur...

[wiztricks]

Salut,

c'est bien le pb, j'ai déjà bouffé un paquet de tutos qui m'ont permis d'arriver à définir ma fenêtre dans une classe, mais je n'en ai pas encore trouvé qui montre clairement comment on communique entre la classe de la fenêtre et le reste du monde

Çà s'appelle la POO. Cà n'a rien de spécifique à Python ou à tkinter. Et vous avez toute une rubrique sur ces sujets.

- W

[alpha.centauri]

oui, c'est bien ce que craignais, je suis pas équipé pour... :-)

ta rubrique est certainement très bien pour ceux qui connaissent bien le sujet, mais, vu mon grand âge, je serai sans-doute mort avant d'avoir trouvé et compris ce qui m'intéresse.

pas grave, je sens que je vais en rester à la ligne de commande...

merci quand même pour ta réponse.