Bon exemple de calculatrice

Soyez le premier à donner votre avis sur cette source.

Vue 1 207 fois - Téléchargée 283 fois

Description

Il y a de nombreux codes sources de calculatrices en C# ou VB.Net.

Les projets de calculatrices, sont des exercices de débutant.
Les codes que l'ont trouve, reflètent donc le niveau du codeur à ce moment de sa formation.
Par conséquent, ces codes présentent tous (enfin ceux que j'ai regardé) des défauts de débutants.
Ils sont généralement fonctionnels, et répondent certainement à la demande du professeur ou cours en ligne que suit le débutant.
Mais CodeS SourceS n'a pas vocation à montrer le résultat d'un exercice.
CodeS SourceS a vocation à montrer ce qu'il faudrait faire.

Ces codes enfreignent souvent quelques précepts généraux de la programmation.
Le principal est la duplication de code.
Il y a un code complet pour la touche "0", et un code pour la touche "1" etc...
Cependant au chiffre près ces codes sont identiques.
On a donc 10 codes quasiments identiques, ça prend du temps à écrire et s'il y a une erreur, il faudra la corriger 10 fois.
Il faut donc factoriser ce code de façon à avoir en paramètre le chiffre à saisir.
Un autre principe souvent oublié est la réutisabilité du code.
En effet, souvent le code est directement écrit dans l'interface, si on veut faire une autre calcultrice et bien on ne pourra pas réutiliser le code directement.
Il faudra en copier un bout ici et en réécrire un bout là.

De plus, C# et VB.Net sont des langages objets, et là encore des principes de la programmation objet ne sont pas appliqués.
Bien souvent, il n'y a pas d'objet métier (c'est l'idée de base....)
En plus un objet métier bien écrit, résout automatiquement les problèmes de duplication et de réutilisabilité.

C'est ce que je veux montrer avec ce dépôt.

Il y a un projet "dll" qui contient le code métier, la dll c'est pas obligé, mais comme j'ai fait 3 interfaces différentes, c'était plus simple.
Pour les interfaces, il y en à une en mode console (pas très ergonomique, ça reste un exemple et une calculatrice en mode console, n'a pas vraiment d'intêret), une en Winform et une en WPF.
Dans l'interface Winform les "chiffres" pointent tous vers une seule méthodes coté interface, idem pour les opérateurs.
Dans l'interface WPF, j'ai factorisé un peu plus, tous les boutons pointent vers une méthode unique.
Pour choisir quelle interface lancer, il faut définir le projet de démarage avec un clic droit sur le nom du projet dans l'explorateur de solution.


Il y a un autre point qui me chagrine dans les dépots de débutants.
La saisie est construite comme du texte, on ajoute un caractère, puis un autre ect...
Sans être un défaut, ça ne me parrait pas logique, on calcule avec des nombres pas du texte.
Et puis si on construit le texte avec un point comme symbole décimal, il faut gérer les pc ou c'est la virgule qui est utilisée.
Aussi, il faut vérifier qu'un point n'a pas déjà été saisi.
J'ai donc construis ma saisie avec des nombres, et bindé l'affichage pour les interfaces fenétrées, comme ça pas de soucis avec le symbole décimal.

Cet exemple n'est pas complet, il ne montre que les 4 opérations de base.
On pourrait le recoder de 1000 façons différentes, tout en appliquant correctement les principes que j'ai cité.
Mais c'est un exemple de "ce qu'il faudrait faire".

Mise à jour du 21/06/2019 => prise en compte des remarques de pascal16m.

Mise à jour du 29/06/2019, suite aux nouvelles remarques de pascal16m sur le problème de précision des doubles:
-changement de la façon de calculer le nombre en cours de saisie, il n'est plus calculé au fur est à mesure en fonction du résultat précédent, mais recalculé entièrement à chaque frappe (utlisation de 2 listes de int)
-limitation à 16 chiffres significatifs, ce qui permet quand même de saisir de 0,00000000000001 à 9999999999999999, en passant par exemple par 12345678,12345678, ce qui est je pense amplement suffisant pour un exemple destiné aux débutants.

Si vous voulez plus d'informations sur les doubles, vous pouvez jetter un oeil à cette discussion (notamment les réponses de Revivax et Dalfab), et à l'article wikipédia que je cite.
Pour effectuer des calculs avec une meilleure précision, on peut utiliser le type Decimal, qui reste un nombre à virgule flottante mais codé sur 64bits.
Ou pour les très grands nombres ou les très petits nombres utiliser ou écrire des classes dédiées.

Codes Sources

A voir également

Ajouter un commentaire

Commentaires

pascal16m
Messages postés
67
Date d'inscription
jeudi 19 juin 2003
Statut
Membre
Dernière intervention
13 juillet 2019
-
Wello,
je trouve le code multi-interface très cool m^me si la saisie en mode de commande est pas user friendly.

La saisie par caractère, ça donne des nombres très bizarres, du genre 4.6649999997 au lieu de 4.6645

Coté programmation, la sélection de la touche ne fait pas la différence entre un opérateur et un chiffre, si on rajoute des boutons on va toujours essayer de les comprendre comme un chiffre. Quand aux exceptions, pour moi, ce ne sont que des infos, pas des exceptions système (très lourdes car gérée comme telles par windows et planter le programme).
Whismeril
Messages postés
14035
Date d'inscription
mardi 11 mars 2003
Statut
Contributeur
Dernière intervention
9 décembre 2019
322 > pascal16m
Messages postés
67
Date d'inscription
jeudi 19 juin 2003
Statut
Membre
Dernière intervention
13 juillet 2019
-
Bonsoir
m^me si la saisie en mode de commande est pas user friendly.

Le but étant de montrer un code réutilisable, je ne me suis pas attardé sur le user-friendly.

La saisie par caractère, ça donne des nombres très bizarres, du genre 4.6649999997 au lieu de 4.6645
ça n'est pas un nombre très bizarre, c'est un nombre à virgule flottante à double précision. 4.6645 n'existe pas en double, pour le voir tel quel, il faut utiliser un artifice d'affichage (un arrondi par exemple)
Plus de détails dans cette discussion https://www.commentcamarche.net/forum/affich-35846831-erreur-de-calcul#3 (pas seulement ma réponse, mais celles de Dalfab et Revivax aussi)

Coté programmation, la sélection de la touche ne fait pas la différence entre un opérateur et un chiffre, si on rajoute des boutons on va toujours essayer de les comprendre comme un chiffre.

Je ne comprends pas ce que tu veux dire, tu as trouvé un bug?
J'ai écrit ce code en quelques heures, l'ai testé comme j'ai pu et corrigé les bugs que j'ai trouvé, mais s'il en reste peux tu les décrire.
Si ce n'est pas ça peux tu être plus explicite?

Quand aux exceptions, pour moi, ce ne sont que des infos, pas des exceptions système (très lourdes car gérée comme telles par windows et planter le programme).
Il est évident que traiter les "erreurs" de saisie autrement que par des exceptions serait bien mieux:
-valeur de retour sur les méthodes
-message
-etc...
Mais là encore, ce n'était pas le but, ce qui est traité par une exception est en dehors du champs de l'exemple que je souhaitais montrer.
pascal16m
Messages postés
67
Date d'inscription
jeudi 19 juin 2003
Statut
Membre
Dernière intervention
13 juillet 2019
-
Wello,
VS s'améliore, hier je ne pouvais pas ouvrir l'interface winform, aujourd'hui je peux (pas mal de bugs dans la version 2019 avec de fausses erreurs signalées qui disparaissent ensuite, la gestion 'en tâche de fond' a pas l'air top).

je parlais du "default: calc.SaisieChiffre(texte);" dans le WPF

Si, par évolution, un bouton renvoie une mauvaise valeur, la valeur sera interprétée comme un chiffre qui générera une erreur à un niveau différent du programme. C'est juste pour générer l'erreur au bon niveau.



pour "du genre 4.6649999997 au lieu de 4.6645 "
c'est quand on continue que ça ressemble bugger car toutes les décimales bougent, ce qui me semble bizarre.
essaies avec 0 . 1 2 3 4 5 6 7 8 9 1 2 3
quand on tape le second 1, ça bug il me semble
Whismeril
Messages postés
14035
Date d'inscription
mardi 11 mars 2003
Statut
Contributeur
Dernière intervention
9 décembre 2019
322 -
Bonsoir
je n'avais pas pris le temps de te répondre, par contre je viens de mettre à jour le source.

pas mal de bugs dans la version 2019 avec de fausses erreurs signalées qui disparaissent ensuite,

Je suppose que tu utilises Community, sa gestion du cache est imparfaite. Souvent, il "suffit" d'éteindre VS, de supprimer le ou les exe et les éventuelles dll générées par ton projet, de supprimer le répertoire obj, de relancer VS et de régénérer la solution.

je parlais du "default: calc.SaisieChiffre(texte);" dans le WPF

Si, par évolution, un bouton renvoie une mauvaise valeur, la valeur sera interprétée comme un chiffre qui générera une erreur à un niveau différent du programme. C'est juste pour générer l'erreur au bon niveau.

Dans la mise à jour, j'ai enlevé la levée d'exception, je l'ai remplacée par des méthodes booléennes et un évènement.

pour "du genre 4.6649999997 au lieu de 4.6645 "
c'est quand on continue que ça ressemble bugger car toutes les décimales bougent, ce qui me semble bizarre.
essaies avec 0 . 1 2 3 4 5 6 7 8 9 1 2 3
quand on tape le second 1, ça bug il me semble

Je n'ai pas envie d'expliquer 50 fois la même chose, dans ma première réponse, je t'ai mis un lien vers un discussion où a été expliquée en détail le pourquoi du comment.
Et je te l'ai déjà dit pour afficher 4.6645, il faut utiliser un artifice d'affichage, mais j'ai implémenté un arrondi dans la mise à jour.
pascal16m
Messages postés
67
Date d'inscription
jeudi 19 juin 2003
Statut
Membre
Dernière intervention
13 juillet 2019
-
premier essai en winform.
plantage avec le nombre 0.123456789123
-> disparition du 8 quand on tape le second 1
-> plantage quand on tape le 2
donc le problème qui n'existe pas n'est pas résolu.

Vous n'êtes pas encore membre ?

inscrivez-vous, c'est gratuit et ça prend moins d'une minute !

Les membres obtiennent plus de réponses que les utilisateurs anonymes.

Le fait d'être membre vous permet d'avoir un suivi détaillé de vos demandes et codes sources.

Le fait d'être membre vous permet d'avoir des options supplémentaires.