POO ET UTILISATION DE QUELQUES BOITES DE DIALOGUE (SAVE ET OPEN) ET DES USERCONT
PCPT
Messages postés
13272
Date d'inscription
lundi 13 décembre 2004
Statut
Membre
Dernière intervention
3 février 2018
-
28 mai 2009 à 09:28
PWM63 Messages postés 127 Date d'inscription lundi 11 octobre 2004 Statut Membre Dernière intervention 18 mai 2016 - 2 juin 2009 à 11:19
PWM63 Messages postés 127 Date d'inscription lundi 11 octobre 2004 Statut Membre Dernière intervention 18 mai 2016 - 2 juin 2009 à 11:19
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/50082-poo-et-utilisation-de-quelques-boites-de-dialogue-save-et-open-et-des-usercontrols
https://codes-sources.commentcamarche.net/source/50082-poo-et-utilisation-de-quelques-boites-de-dialogue-save-et-open-et-des-usercontrols
2 juin 2009 à 11:19
Si tu n'as qu'un seul type de contrôle par formulaire, ça passe à la rigueur.
Le jour où tu te retrouves avec 50 textbox ou 30 combobox ou 10 boutons ou etc..., et que tu devras revenir sur ton code pour corriger 1 bug ou pour optimiser une fonctionnalité, tu remarqueras peut-être le temps que tu vas perdre à savoir qui est qui.
De plus, si tu adresses ta source aux débutants, comment-veux tu qu'ils assimilent le code s'ils ne savent pas de quoi il s'agit ?
Qu'est ce qui est le plus clair ?
Ceci ?
TextBox1
TextBox2
TextBox3
TextBox4
TextBox5
ComboBox1
ComboBox2
ComboBox3
Button1
Button2
Button3
ou celà ?
TextBox_Nom
TextBox_Prénom
TextBox_Adresse
TextBox_CP
TextBox_Ville
ComboBox_Niveau
ComboBox_ListeVerte
ComboBox_ListeRouge
Button_OK
Button_Appliquer
Button_Annuler
Nommer explicitement ses contrôles est une évidence.
31 mai 2009 à 16:55
qu'on hésite à renommer un bouton en "btnAction, Btn_Action, Cmd_Action", ok. mais plus généralement avoir 50 boutons et les laisser nommés par défaut ne peut que nuire à tout le monde (lecteur averti qui cherche lequel est où, lecteur débutant qui passe encore plus de temps à chercher tout en prenant aussi de mauvaises habitudes, et aussi l'auteur qui reste dans le 2e cas)
le framework et plus généralement dotnet (vb, c#, etc..) donc l'IDE par lui-même ont été fait de manière à accélérer le temps de RéALISATION de code
(reste à prendre le temps de comprendre les subtilités de quoi utiliser au lieu de quoi, même s'il y a toujours plusieurs manières de faire la même chose)
le temps gagné ne doit pas être re-perdu parce qu'on a pas ouvert son projet pendant 2 mois.
on lit par exemple "
sub cmdReadFile_Click(...)
dim reader as io.textreader = io.file.opentext(txtFile.text)"
, on sait tout de suite qu'on va récupérer le contenu d'un 'fichier' dont le 'chemin' est dans une 'zone de texte', ce par l'action 'click' d'un 'bouton'. on n'a pas besoin d'aller vérifier sur le formulaire où est le bouton command45 (nommer suffit ici à ne pas avoir besoin de connaître son emplacement), ni que c'est un chemin ou une chaine (on sait), ni que c'est une zone de texte, ni ou elle est, etc...
on doit pouvoir comprendre à la simple lecture sans même (pour les petits projets) avoir besoin de regarder l'interface
on peut comprendre éventuellement qu'un label NON utilisé par code (ex : label13.text = "machin") ne soit pas nommé, ce n'est qu'une étiquette graphique utilisée qu'en mode design, pour tout contrôle lié à du code il est nécessaire de se forcer à s'organiser (surtout comme le souligne nhervagault quand on est sujet à toucher à plusieurs langages)
on comprend bien sûr que çà ne se fasse pas en un claquement de doigts, mais refuser cet effort ne peut mener qu'à des confusions et, quand on souhaite partager ses sources, qu'à - au final - des échanges inutiles par nature
(cette intervention en haut de la liste évidemment :))
31 mai 2009 à 15:45
Oui, ce n'est pas un exemple c'est sur, autant leur montrer que rennommer ses contrôles c'est organiser son travail, mais si l'exemple leurs parrait illisible, alors il ne sert plus à rien, d'ailleurs, dans les exemples MSDN les controles ne sont pas toujours renommés.
28 mai 2009 à 23:44
merci ;)
28 mai 2009 à 23:33
Pour le point 1 btnPrecendent est plus parlant que button1 et le programme devient plus maintenable.
De plus, par exemple le point 3. permet une performance plus intéressante (pas de casting implicite qui fait appele a la
reflexion)
Je sais que pour une petite application,c'est pas trop grave mais si tu veux montrer une maniere de programmer mieux vaut qu'elle soit la plus correcte possible ;-)
Pour le point 5.
# TextBox1.Text = prod.aRefProd
# TextBox2.Text = prod.aNomProd
# ComboBox1.Text = prod.aCategorie
# TextBox3.Text = prod.aPrixU
# TextBox4.Text = prod.aNomFournisseur
Est present plusieurs fois
--> une fonction
sub fill(prod as Produit)
TextBox1.Text = prod.aRefProd
TextBox2.Text = prod.aNomProd
ComboBox1.Text = prod.aCategorie
TextBox3.Text = prod.aPrixU
TextBox4.Text = prod.aNomFournisseur
end sub
Et Voila 15 lignes de code de gagnées
et si tu ajoutes un champ exemple TVA tu as que cette fonction à modifier.
à la place de 4 fonctions.
Point6 si un jour tu passes par exemple au c# tu auras moins de probleme en appliquant ces regles.
28 mai 2009 à 22:35
et je pense que les débutants ne seront pas d'accord avec toi ;)
cordialement,
28 mai 2009 à 22:19
1 --> je vois pas le probleme entre laisser les noms par defaut aux "controls" ou les changer
2 -->je sais qu'il faut utilisé des classes en POO et je les fait (la classe : produit.vb)
3 -->je ne vois pas le probleme entre lutilisation d'un arraylist ou de List<t>, sa marche sans probleme
4 -->je vais voir ce que je peux faire pour sa
5 -->peut tu etre plus explicite
6 -->puisque je programme en VB alors pour quio ne pas utilisé ce que VB propose?
merci pour le commentaire ;)
28 mai 2009 à 20:03
Je ne vois pas trop l'interet de la source.
1 --> Les boutons ont leur nom par défaut
2 --> En POO on n'utilise pas les modules (mais des classes)
3 --> Utilise les List<T> a la place de l'arraylist
4 --> utilise option strict et option explicit (pour ne pas avoir des conversions implicite cas de l'arraylist)
5 --> factorise le remplissage des champs car dans ce code tu as 5 fois la meme chose
6 --> evite d'utiliser des fonctions specifique vb (val --> int32.parse)
Voici quelques points pour améliorer ton programme.
28 mai 2009 à 15:23
28 mai 2009 à 14:58
Par contre quand je répond au forum, il y a souvant des questions sur les contrôles de base de vb, je pourrais alors les redirigés vers ta source ;)
28 mai 2009 à 14:08
le programme ne sert pas à stocker ou quelque chose comme ça
mais juste un exemple de creation d'un objet ni + ni -
je vais le precisé dans la description
merci encore
28 mai 2009 à 13:19
Ton code n'est pas mal, c'est un bon tuto pour débutant, cependant je trouve que tu as mal choisi l'exemple de programme.
Pour ce type de programme on utilise en générale une base de données et on évite ainsi de saisir au moins 50% du code qui compose ton application, si ce n'est plus...
Le petit reproche que j'aurais à faire à ta source est que si un nouveau se lançant dans le développement lit ta source, pour créer une application de données il suivra ton exemple qui n'est pas en effet le plus approprié.
Pour le reste, ton code est propre, un peu trop légèrement commenté, mais comme il est assez simple à comprendre cela compense.
Ce que je trouve simpa en revanche, c'est qu'il démontre l'utilisation des contrôles de base et de leurs propriétés, et la création d'une classe "métier".
28 mai 2009 à 12:02
28 mai 2009 à 09:28
"go to zip" pourquoi pas, encore faut-il le joindre :)