Calcufolio

Une calculatrice desktop centrée sur la saisie, l’édition et l’évaluation d’expressions.

Objectif: Relier un moteur d’expressions à une interface Avalonia.
Points clés: Parser, séparation des couches, MVVM, tests automatisés et CI .NET.

Domaines

Dépôt GitHub Télécharger le CV

Fenêtre Calcufolio affichant le résultat 72 et plusieurs calculs dans le panneau History. — Résultat courant et historique de plusieurs expressions évaluées.

Problème

Le problème à résoudre

Construire une calculatrice desktop dont le parsing, l’édition, l’état d’interaction et l’interface restent découplés afin de tester les comportements complexes sans dépendre d’Avalonia.

Architecture

Les pièces du système

Solution séparée en Domain, Application, Infrastructure et Presentation.
Moteur d’expressions dans la couche Application avec tokenization, parsing, modèle syntaxique, évaluation et erreurs typées.
Modèle d’interaction basé sur contrôleur, actions, état d’éditeur et reducer pour isoler les comportements de saisie.
Présentation Avalonia structurée en MVVM avec CommunityToolkit.Mvvm, historique et aperçu de calcul.

Décisions

Décisions techniques

Découpler le moteur d’expressions de l’interface. Le parsing et l’évaluation restent testables sans instancier Avalonia, ce qui évite de placer la logique de calcul dans les événements de boutons.
Modéliser l’édition comme un état explicite. Caret, sélection, insertion, suppression et actions clavier passent par un état et des transformations dédiées plutôt que par des mutations dispersées.
Utiliser MVVM pour la présentation. CommunityToolkit.Mvvm réduit le code de liaison tout en gardant le ViewModel indépendant de la vue Avalonia.
Épingler la toolchain .NET. global.json fixe le SDK .NET 10 attendu et la CI utilise la même référence pour limiter les divergences entre poste local et runner.

Schéma

Vue d’ensemble de l’architecture

Le schéma complète l’étude de cas avec les composants et frontières réellement présents dans le projet.

Schéma du flux Calcufolio depuis Avalonia et les contrôleurs applicatifs jusqu’au tokenizer, parser, évaluateur et moteur de calcul. — Flux d’interaction et moteur d’expressions de Calcufolio.

Implémentation

Points techniques principaux

Moteur d’expressions séparé en tokenizer, parser, modèle syntaxique et évaluateur.
Services de calcul et d’évaluation indépendants de la couche Avalonia.
Modèle d’interaction avec contrôleur, actions, état d’éditeur, reducer, sélection, clavier et presse-papiers.
Présentation Avalonia structurée en MVVM avec CommunityToolkit.Mvvm, aperçu de calcul et historique.
Tests automatisés des couches Domain, Application et Presentation, notamment tokenizer, parser et évaluateur.
CI GitHub Actions : syntaxe, ShellCheck, restore, format, build, tests et audit des dépendances NuGet.

Difficultés

Difficultés résolues

Maintenir un éditeur cohérent. Insertion, backspace, suppression avant, sélection, déplacements du caret et presse-papiers doivent produire un état prévisible quelle que soit l’entrée.
Évaluer des expressions sans coupler la syntaxe à l’UI. Tokenizer, parser et evaluator doivent gérer précédence et erreurs de manière déterministe avant que le résultat soit projeté dans le ViewModel.
Synchroniser aperçu, résultat et historique. Le ViewModel dérive l’affichage depuis l’état applicatif et reconstruit l’historique sans déplacer la logique de calcul dans la présentation.

Qualité

Tests et garde-fous

Tests automatisés sur les couches Domain, Application et Presentation, notamment tokenizer, parser, évaluateur et interactions.
Vérification dotnet format afin d’éviter les divergences de style dans la solution.
Audit des dépendances NuGet intégré à la quality gate.

Livraison

Livraison et CI/CD

Workflow develop : syntaxe, ShellCheck, restore, format, build, tests et audit NuGet.
Workflows distincts également présents pour testing et main.
SDK .NET 10 épinglé par global.json et commandes de validation exposées par le Makefile.

Résultats

Résultats observables

Une calculatrice dont le moteur d’expressions peut être testé indépendamment du framework graphique.
Un modèle d’édition capable de représenter sélection et caret plutôt qu’une simple chaîne concaténée.
Une chaîne CI .NET reproductible qui vérifie compilation, tests, formatage et dépendances.

Compromis

Compromis techniques

L’architecture comporte davantage de couches qu’une calculatrice minimale afin d’isoler le moteur d’expressions, l’état d’édition et la présentation.
Un moteur de parsing dédié demande plus de code qu’une évaluation directe depuis l’UI, mais permet de contrôler la syntaxe, les erreurs et la précédence.
Le projet est encore en cours : l’accent porte actuellement davantage sur les fondations et la qualité que sur un catalogue maximal de fonctions scientifiques.

Limites

Les limites actuelles

Le projet reste en cours et n’est pas présenté comme une application finalisée.
Le README public actuel documente peu l’architecture et les fonctions présentes dans le dépôt.
Le périmètre fonctionnel doit encore être consolidé avant de considérer une release utilisateur stable.

Suite

Prochaines étapes

Enrichir le README public avec architecture, captures, lancement, tests et limites.
Poursuivre les fonctions de calcul et les comportements d’édition sans contourner le moteur d’état existant.
Préparer un packaging/release utilisateur lorsque le périmètre fonctionnel sera suffisamment stabilisé.

Captures

Le produit en situation

Quelques écrans pour parcourir le projet.

Fenêtre Calcufolio avec une expression arithmétique et la sous-expression 8 + 4 sélectionnée. — Édition d’expression avec sélection explicite avant évaluation.

Synthèse

Compétences et techniques mobilisées

Tokenizer, parser, évaluateur, modèle d’interaction et présentation Avalonia sont répartis dans des couches distinctes.
Sélection, caret, insertion, suppression et évaluation sont couverts par des états et tests indépendants d’Avalonia.
global.json épingle le SDK .NET 10 ; la CI exécute formatage, build, tests et audit NuGet.