Einheitenumrechner: Temperatur

In diesem Artikel erläutert Tamás, einer unserer Bibliotheksentwickler, die Entwicklungsentscheidungen hinter der in der Bibliothek verfügbaren Baustein-App „Unit Converter: Temperature“.

Warum ich eine Objektliste anstelle einer Tabelle verwendet habe

Hallo, ich bin Tamás von Tulip.

Für diese Komponente habe ich mich für eine Objektliste entschieden, die als Standardwerte für Variablen gespeichert ist, da sich der Datensatz selten ändert und keine tabellenbasierte Verwaltung erfordert.

In diesem Fall handelt es sich bei den Temperaturumrechnungsfaktoren und Offsets um statische mathematische Beziehungen. Sie erfordern keine Bearbeitung zur Laufzeit, keine Aggregation und keine relationalen Abfragen. Aus diesem Grund habe ich bewusst auf die Verwendung einer Tabelle verzichtet. Stattdessen:* speichere ich die Umrechnungsdefinitionen in einer Variablen* wird die Variable mit Standardwerten initialisiert* bietet die Objektliste eine strukturierte und gut lesbare Datenansicht* ist keine Tabellenaggregationslogik erforderlich

Dieser Ansatz sorgt dafür, dass die Komponente schlank und in sich geschlossen bleibt.

Warum keine Tabelle?

Die Verwendung einer Tabelle würde Folgendes mit sich bringen:* Die Notwendigkeit, der App eine zusätzliche Tabelle hinzuzufügen* Die Notwendigkeit, eine Abfrage für diese Tabelle zu erstellen* Die Notwendigkeit, eine Aggregationslogik für diese Abfrage zu konfigurieren* Die Notwendigkeit, diese Abfrage und Aggregation ebenfalls in der App hinzuzufügen und zu pflegen

Bei einem Datensatz, der sich selten ändert, ist dieser Aufwand unnötig.

Durch das Speichern der Umrechnungsdefinitionen als Standardwerte in einer Variablen:* Wird die Komponente vollständig portabel* Beim Kopieren der App wird auch die Datenstruktur kopiert* Es ist keine externe Abhängigkeit erforderlich

Die Objektliste bietet eine übersichtliche, strukturierte Darstellung der zugehörigen Attribute (inputUnit-targetUnit, Faktor, Offset), ohne dass relationale Logik erforderlich ist.

Entwurfsprinzip: Geschützte Logik, flexible Konfiguration

Die Komponente wurde nach einem zentralen Prinzip entworfen:

Die Kernlogik sollte niemals geändert werden müssen.

Um dies zu gewährleisten, habe ich interne Komponentenvariablen eingeführt und diese mit einem vorangestellten Unterstrich gekennzeichnet (zum Beispiel _temperatureInputUnit). Diese Unterstrich-Variablen fungieren als stabile interne Schnittstellen, auf die sich die geschützte Kernlogik verlassen kann.

Kompromiss: Die Verwendung interner Variablen erfordert zwei kleine Konfigurationsauslöser:* 01 – USER CONFIG: INPUT STAGE ordnet externe Quellen internen Variablen zu* 03 – USER CONFIG: OUTPUT STAGE ordnet das interne Ergebnis dem gewünschten Ziel zu

Dadurch entsteht eine dünne Konfigurationsschicht um die geschützte Engine herum, der MAGIC-Trigger bleibt jedoch unverändert und lässt sich weiterhin einfach per Kopieren und Einfügen verwenden.

Alternative Option

Ein einfacherer – aber weniger wartungsfreundlicher – Ansatz wäre, externe Verweise direkt in den Kernausdruck einzufügen (beispielsweise mithilfe einer App-Variablen oder eines „ table record field “-Platzhalters inline).

Dadurch werden zwar die zusätzlichen Konfigurations-Trigger vermieden, jedoch wird die Portabilität eingeschränkt und die Wiederverwendbarkeit erschwert, da bei jeder Kopie die Kernlogik bearbeitet werden muss.

Für die Komponentenverteilung ist das Schnittstellenmuster mit internen Variablen einfacher zu verwalten: Ein- und Ausgänge werden an den Rändern konfiguriert, während die Berechnungs-Engine stabil und geschützt bleibt.

Der MAGIC-Trigger führt eine Suche durch und wendet eine affine Transformation an:

Ergebnis = (Wert × Faktor) + Offset

Da die Konvertierungsdefinitionen in der internen Objektliste zentralisiert sind, kann der Trigger mehrere Fälle ohne Änderung verarbeiten.

In dieser Implementierung:* °C, K und °F werden unterstützt* Alle 3×3-Kombinationen sind vordefiniert* Die Logik ermittelt dynamisch den richtigen Faktor und Offset

Der App-Entwickler muss lediglich:1. Die Eingangsquellen konfigurieren2. Das Ausgabeziel konfigurieren

Kein Umschreiben von Formeln. Keine Bearbeitung der bedingten Logik. Keine strukturellen Änderungen.

Warum dies skalierbar ist

Diese Struktur ermöglicht:* Das Hinzufügen neuer Einheiten durch Erweiterung der Objektliste* Die Beibehaltung der Berechnungs-Engine ohne Änderungen* Die Wahrung der architektonischen Konsistenz über alle Apps hinweg* Die schnelle Wiederverwendung in mehreren Projekten

Die Komponente trennt:* Die Konfiguration der Datenquellen (Eingabestufe)* Die Ausführungslogik (MAGIC)* Die Weiterleitung der Ergebnisse (Ausgabestufe)

Diese Trennung sorgt dafür, dass das System sicher, vorhersehbar und skalierbar bleibt.

Aufschlüsselung des Triggers – So funktioniert MAGIC (Ausdruck)

Der geschützte MAGIC-Trigger ist als einzelner Ausdruck implementiert:(@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 ))Im Großen und Ganzen führt dieser Ausdruck drei Schritte aus:

1. Erstellen des Lookup-Schlüssels

Der Schlüssel wird dynamisch aus den konfigurierten Eingabevariablen gebildet:

inputUnit-targetUnit

Beispiel:

°C-°F

Dadurch wird sichergestellt, dass die Logik generisch bleibt und für alle unterstützten Kombinationen funktioniert.

2. Faktor und Offset aus der Objektliste ermitteln

Der Ausdruck ermittelt Faktor und Offset in einem Durchgang:* map_to_text_list(..., 'inputUnit-targetUnit') erstellt die Liste der Nachschlagsschlüssel im laufenden Betrieb.* array_index_of(...) ermittelt den Index des passenden Schlüssels.* array_value_at_index(...) verwendet diesen Index, um die entsprechenden Werte aus den Faktor- und Offset-Listen abzurufen.

Die entscheidende Designentscheidung hierbei ist die direkte Verknüpfung von array\_index\_of(...) mit map\_to\_text\_list(...). Dadurch wird vermieden, dass eine Zwischenliste der Schlüssel in einer separaten Variablen gespeichert wird. Stattdessen wird die Nachschlageliste inline generiert und sofort verwendet, um sowohl den Faktor als auch den Offset innerhalb eines einzigen Ausdrucks abzurufen.

Dadurch bleibt der MAGIC-Trigger in sich geschlossen und der Konfigurationsaufwand wird reduziert, während er sich dennoch wie eine strukturierte Nachschlageliste verhält – ohne dass eine Tabelle oder Aggregationslogik erforderlich ist.

3. Anwenden der affinen Transformation

Sobald der richtige Faktor und der richtige Offset ermittelt sind, wird die Berechnung angewendet:

Ergebnis = (Wert × Faktor) + Offset

Da die Nachschlagelogik indexbasiert und datengesteuert ist, benötigt der Trigger keine bedingten Verzweigungen oder „switch-case“-Strukturen.

Warum diese Struktur gewählt wurde

• Sie vermeidet fest codierte bedingte Logik.
• Sie lässt sich nahtlos skalieren, wenn neue Einheitenkombinationen hinzugefügt werden.
• Dadurch bleibt die Berechnung vollständig datengesteuert.
• Es wird ein einziger geschützter Ausdruck anstelle mehrerer Trigger beibehalten.

Dieses Design sorgt dafür, dass die Komponente deterministisch, erweiterbar und vor versehentlichen Änderungen an der Logik geschützt bleibt.

Erweiterung um neue Einheiten

Um eine neue Einheit hinzuzufügen, erweitern Sie _temperatureConversionDefaults durch einen neuen Eintrag, der Folgendes enthält:* inputUnit-targetUnit (Schlüssel)* Faktor* Offset

Sobald die neue Zuordnung in der Objektliste vorhanden ist, kann der geschützte MAGIC-Trigger sie automatisch auflösen – Änderungen an der Kernlogik sind nicht erforderlich.

Fehlerbehandlung (Safe-Lookup-Muster)

Der MAGIC-Trigger verfügt über eine explizite Fehlererkennung, um eine sichere Ausführung zu gewährleisten, wenn ein Umrechnungspaar nicht gefunden wird. Anstatt sich auf ein leeres Ergebnis zu verlassen, überprüft der Trigger den Lookup-Index direkt:

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

Wenn der zurückgegebene Index -1 ist, existiert keine passende Umrechnungsregel.

Ausführungsablauf: 1. _temperatureConversionResult zu Beginn des Triggers löschen. 2. Wenn Suchindex = -1 → keine Berechnung durchführen. 3. Andernfalls → berechnen und das Ergebnis speichern.

Die OUTPUT-Stufe prüft anschließend:

Wenn _temperatureConversionResult leer ist → Fehlermeldung anzeigen.

Beispielmeldung:

„Für das ausgewählte Einheitenpaar wurde keine Umrechnungsregel gefunden. Überprüfen Sie das Einheitenformat (°C, K, °F) und stellen Sie sicher, dass das Paar in _temperatureConversionDefaults vorhanden ist.“

Dies gewährleistet:• Es verbleiben keine veralteten Werte aus früheren Ausführungen • Es wird keine Berechnung ohne gültige Regel versucht • Der Benutzer erhält eine klare und umsetzbare Fehlermeldung

Die Kernlogik bleibt geschützt und unverändert und gewährleistet dennoch ein deterministisches und sicheres Verhalten.

Warum keine separaten Arrays für Schlüssel, Faktoren und Offsets?

Ein alternativer Ansatz wäre gewesen, Folgendes zu speichern:* Die Nachschlage-Schlüssel in einem Array* Die Faktoren in einem anderen Array* Die Offsets in einem dritten Array

Dies würde zwar technisch funktionieren, würde jedoch ein strukturelles Risiko mit sich bringen: Die positionelle Beziehung zwischen den Arrays muss stets perfekt aufeinander abgestimmt bleiben.

Ändert sich die Reihenfolge eines Arrays, während die anderen unverändert bleiben, würde die Beziehung zwischen Schlüssel, Faktor und Offset unbemerkt zusammenbrechen, was zu falschen Umrechnungen führen würde.

Durch die gemeinsame Speicherung verwandter Attribute in einer Objektliste bleiben die Werte für „inputUnit“, „targetUnit“, „Faktor“ und „Offset“ jedes Eintrags logisch gruppiert. Dies verringert das Risiko einer Fehlausrichtung und macht die Struktur sicherer und einfacher zu warten.

Machen Sie mit

Treten Sie der Community bei, um Verbesserungen zu teilen, zusätzliche Einheiten vorzuschlagen, Probleme zu melden oder architektonische Entscheidungen zu diskutieren.