Convertisseur d'unités : Température

Dans cet article, Tamás, l’un de nos développeurs de la bibliothèque, revient sur les choix techniques qui ont présidé au développement de l’application « Convertisseur d’unités : Température », disponible dans la bibliothèque.

Pourquoi j’ai utilisé une liste d’objets plutôt qu’un tableau

Bonjour, je m’appelle Tamás et je travaille chez Tulip.

Pour ce composant, j’ai décidé d’utiliser une liste d’objets stockée sous forme de valeurs de variables par défaut, car l’ensemble de données change rarement et ne nécessite pas de gestion sous forme de tableau.

Dans ce cas précis, les facteurs de conversion et les décalages de température sont des relations mathématiques statiques. Ils ne nécessitent ni modification à l'exécution, ni agrégation, ni requêtes relationnelles. C'est pourquoi j'ai délibérément évité d'utiliser un tableau. À la place :* Je stocke les définitions de conversion dans une variable* La variable est initialisée avec des valeurs par défaut* La liste d'objets offre une vue structurée et lisible des données* Aucune logique d'agrégation de tableau n'est requise

Cette approche permet de conserver un composant léger et autonome.

Pourquoi pas un tableau ?

L’utilisation d’un tableau impliquerait :* La nécessité d’ajouter un tableau supplémentaire à l’application* La nécessité de créer une requête sur ce tableau* La nécessité de configurer une logique d’agrégation pour cette requête* La nécessité d’ajouter et de maintenir cette requête et cette agrégation au sein de l’application également

Pour un ensemble de données qui évolue rarement, cette surcharge est inutile.

En stockant les définitions de conversion sous forme de valeurs par défaut dans une variable :* Le composant devient entièrement portable* La copie de l’application entraîne également la copie de la structure de données* Aucune dépendance externe n’est requise

La liste d’objets offre une vue claire et structurée des attributs associés (inputUnit-targetUnit, facteur, décalage) sans nécessiter de logique relationnelle.

Principe de conception : logique protégée, configuration flexible

Le composant a été conçu selon un principe clé :

La logique centrale ne doit jamais nécessiter de modification.

Pour ce faire, j’ai introduit des variables internes au composant et je les ai marquées d’un trait de soulignement en début de nom (par exemple, _temperatureInputUnit). Ces variables avec trait de soulignement agissent comme des interfaces internes stables sur lesquelles la logique centrale protégée peut s’appuyer.

Compromis : l’utilisation de variables internes nécessite deux petits déclencheurs de configuration :* 01 – CONFIGURATION UTILISATEUR : L’ÉTAPE D’ENTRÉE mappe les sources externes vers les variables internes* 03 – CONFIGURATION UTILISATEUR : L’ÉTAPE DE SORTIE mappe le résultat interne vers la destination souhaitée

Cela ajoute une fine couche de configuration autour du moteur protégé, tout en laissant le déclencheur MAGIC inchangé et facile à copier-coller.

Option alternative

Une approche plus simple — mais moins facile à maintenir — consisterait à coller directement les références externes dans l’expression principale (par exemple, en utilisant une variable d’application ou un espace réservé « table record field » en ligne).

Cela évite les déclencheurs de configuration supplémentaires, mais réduit la portabilité et rend la réutilisation plus difficile, car chaque copie nécessite de modifier la logique centrale.

Pour la distribution des composants, le modèle d’interface à variables internes est plus facile à gérer : les entrées et les sorties sont configurées aux extrémités, tandis que le moteur de calcul reste stable et protégé.

Le déclencheur MAGIC effectue une recherche et applique une transformation affine :

résultat = (valeur × facteur) + décalage

Comme les définitions de conversion sont centralisées dans la liste d’objets interne, le déclencheur peut gérer plusieurs cas sans modification.

Dans cette implémentation :* Les unités °C, K et °F sont prises en charge* Toutes les combinaisons 3×3 sont prédéfinies* La logique détermine dynamiquement le facteur et le décalage corrects

Le développeur d’applications n’a qu’à :1. Configurer les sources d’entrée2. Configurer la destination de sortie

Pas de réécriture de formule. Pas de modification de la logique conditionnelle. Pas de changements structurels.

Pourquoi cette approche est évolutive

Cette structure permet :* D’ajouter de nouvelles unités en étendant la liste d’objets* De ne pas modifier le moteur de calcul* De maintenir la cohérence architecturale entre les applications* Une réutilisation rapide sur plusieurs projets

Le composant sépare :* La configuration des sources de données (étape d’entrée)* La logique d’exécution (MAGIC)* L’acheminement des résultats (étape de sortie)

Cette séparation garantit la sécurité, la prévisibilité et l’évolutivité du système.

Analyse du déclencheur – Comment fonctionne le MAGIC (expression)

Le déclencheur MAGIC protégé est implémenté sous la forme d’une expression unique :(@Variable._temperatureInputValue * array_value_at_index( map_to_number_list(@Variable._temperatureConversionDefaults , 'factor'), array_index_of( map_to_text_list(@Variable._temperatureConversionDefaults , 'inputUnit-targetUnit'), @Variable._temperatureInputUnit + '-' + @Variable._temperatureTargetUnit )))+array_value_at_index( map_to_number_list(@Variable._temperatureConversionDefaults , 'offset'), array_index_of( map_to_text_list(@Variable._temperatureConversionDefaults , 'inputUnit-targetUnit'), @Variable._temperatureInputUnit + '-' + @Variable._temperatureTargetUnit ))De manière générale, cette expression effectue trois étapes :

1. Création de la clé de recherche

La clé est construite dynamiquement à partir des variables d’entrée configurées :

unité_d’entrée-unité_cible

Par exemple :

°C-°F

Cela garantit que la logique reste générique et fonctionne pour toutes les combinaisons prises en charge.

2. Déterminer le facteur et le décalage à partir de la liste d’objets

L'expression détermine le facteur et le décalage en un seul passage :* map_to_text_list(..., 'unité_source-unité_cible') construit la liste des clés de recherche à la volée.* array_index_of(...) trouve l’index de la clé correspondante.* array_value_at_index(...) utilise cet index pour extraire les valeurs correspondantes des listes de facteur et de décalage.

Le choix de conception clé ici consiste à combiner directement array\_index\_of(...) avec map\_to\_text\_list(...). Cela évite de stocker une liste de clés intermédiaire dans une variable distincte. Au lieu de cela, la liste de recherche est générée en ligne et immédiatement utilisée pour récupérer à la fois le facteur et le décalage au sein d’une seule expression.

Cela permet au déclencheur MAGIC de rester autonome et réduit la surface de configuration, tout en conservant le comportement d’une recherche structurée — sans nécessiter de table ni de logique d’agrégation.

3. Appliquer la transformation affine

Une fois le facteur et le décalage corrects déterminés, le calcul est appliqué :

résultat = (valeur × facteur) + décalage

La logique de recherche étant basée sur des index et pilotée par les données, le déclencheur ne nécessite ni branchement conditionnel ni structures switch-case.

Pourquoi cette structure a-t-elle été choisie ?

• Elle évite la logique conditionnelle codée en dur.
• Elle s'adapte naturellement à l'ajout de nouvelles combinaisons d'unités.
• Elle permet de conserver un calcul entièrement piloté par les données.
• Elle conserve une seule expression protégée au lieu de plusieurs déclencheurs.

Cette conception garantit que le composant reste déterministe, extensible et à l'abri de toute modification accidentelle de la logique.

Extension avec de nouvelles unités

Pour ajouter une nouvelle unité, étendez _temperatureConversionDefaults en ajoutant une nouvelle entrée comprenant :* inputUnit-targetUnit (clé)* facteur* décalage

Une fois que le nouveau mappage figure dans la liste des objets, le déclencheur MAGIC protégé peut le résoudre automatiquement — aucune modification de la logique centrale n’est requise.

Gestion des échecs (modèle de recherche sécurisé)

Le déclencheur MAGIC intègre une détection explicite des échecs afin de garantir une exécution sécurisée lorsqu’une paire de conversion est introuvable. Au lieu de se contenter d’un résultat vide, le déclencheur vérifie directement l’index de recherche :

ARRAY_INDEX_OF( MAP_TO_TEXT_LIST(_temperatureConversionDefaults, 'inputUnit-targetUnit'), _temperatureInputUnit + '-' + _temperatureTargetUnit )

Si l’index renvoyé est égal à -1, aucune règle de conversion correspondante n’existe.

Déroulement de l’exécution : 1. Effacer _temperatureConversionResult au début du déclencheur. 2. Si l’index de recherche = -1 → ne pas effectuer de calcul. 3. Sinon → effectuer le calcul et stocker le résultat.

L'étape OUTPUT vérifie ensuite :

Si _temperatureConversionResult est vide → afficher un message d’erreur.

Exemple de message :

« Aucune règle de conversion trouvée pour la paire d’unités sélectionnée. Vérifiez le format des unités (°C, K, °F) et assurez-vous que la paire existe dans _temperatureConversionDefaults. »

Cela garantit :• qu’aucune valeur obsolète issue d’exécutions précédentes ne subsiste • qu’aucun calcul n’est tenté sans règle valide • que l’utilisateur reçoit un message d’erreur clair et exploitable

La logique centrale reste protégée et inchangée, tout en garantissant un comportement déterministe et sûr.

Pourquoi ne pas utiliser des tableaux distincts pour les clés, les facteurs et les décalages ?

Une autre approche aurait consisté à stocker :* Les clés de recherche dans un tableau* Les facteurs dans un autre tableau* Les décalages dans un troisième tableau

Bien que cela fonctionne techniquement, cela introduirait un risque structurel : la relation de position entre les tableaux doit toujours rester parfaitement alignée.

Si l’ordre d’un tableau change et que celui des autres reste inchangé, la relation clé-facteur-décalage serait rompue de manière silencieuse, ce qui entraînerait des conversions incorrectes.

En stockant les attributs associés ensemble dans une liste d’objets, chaque entrée conserve ses valeurs inputUnit-targetUnit, facteur et décalage regroupées de manière logique. Cela réduit le risque de désalignement et rend la structure plus sûre et plus facile à maintenir.

Participez

Rejoignez la communauté pour partager des améliorations, proposer des unités supplémentaires, signaler des problèmes ou discuter des choix architecturaux.