Eine JSON-Reparatur darf ihre Nebenwirkungen zeigen
Typprüfung, Eingabeschutz und Idempotenz getrennt überprüfen.
Auch ohne Netzwerk ist eine Funktion nicht automatisch rein. Wenn sie ein übergebenes verschachteltes Objekt verändert, verändert sie Zustand des Aufrufers. Eine flache Kopie schützt nur die äußere Hülle; gemeinsam referenzierte Kinder können weiterhin mutieren. Unser Übungsvertrag lautet: Ergebnis, Änderungen und Fehler zurückgeben, Eingabe unverändert lassen. Für jedes Feld prüft er fehlendes Elternobjekt, gültiges JSON mit falschem Typ, beschädigten Text und absichtlich leere Werte. Defaults dürfen nur ausdrücklich erlaubte Lücken füllen. Idempotenz ist eine andere Eigenschaft: Ein zweiter Durchlauf ändert nichts mehr. Eine Funktion kann idempotent sein und trotzdem beim ersten Aufruf die Eingabe verändern. Beide Zusagen brauchen eigene Tests.
Ein Beispiel
Ein fiktiver Datensatz enthält attributes={label:''}. Der leere Titel ist laut Vertrag erlaubt. Die Transformation darf ihn nicht mit Unbekannt überschreiben. Fehlt attributes ganz, legt der Vertrag entweder eine erlaubte Struktur an oder meldet einen Fehler; er darf nicht beim späteren Schreiben scheitern. Im Code wird für ein neues JSON-artiges Ergebnis rekursiv kopiert und nur ein neuer Standard ergänzt. Dieser kurze Ausschnitt setzt ein validiertes Dictionary voraus; die vollständige Fehlerklassifikation ist eine eigene Aufgabe.
Python 3.11 · Lehrbeispiel
from copy import deepcopy
def transform(value):
result = deepcopy(value)
result.setdefault("attributes", {}).setdefault("visible", True)
return result
original = {"attributes": {"label": ""}}
result = transform(original)
print("visible" in original["attributes"], transform(result) == result)
Erwartete Ausgabe
False True