Benefits of Applying Software Design Patterns to Backend Rust Applications
Diese Arbeit evaluiert empirisch die Auswirkungen der Anwendung der Typestate- und Newtype-Entwurfsmuster auf produktive Rust-Backend-Anwendungen und stellt fest, dass Typestate die Fehlerfreiheit und Testbarkeit auf Kosten der Lesbarkeit signifikant verbessert, während das Newtype-Muster durch die Vermeidung ungültiger Laufzeitzustände einen hohen Ertrag bei geringem Aufwand bietet.
Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen
Stellen Sie sich vor, Sie bauen eine komplexe Maschine, wie etwa eine hochwertige Kaffeemaschine. Sie wollen, dass sie schnell, zuverlässig und leicht zu reparieren ist, falls etwas schiefgeht. In der Welt der Softwareentwicklung ist die Sprache Rust wie ein sehr strenger, sicherheitsbewusster Ingenieur, der sich weigert, etwas zu bauen, das später vielleicht undicht wird oder kaputtgeht. Aber selbst mit einem strengen Ingenieur benötigen Sie einen guten Bauplan, um sicherzustellen, dass die Maschine leicht zu verstehen und zu modifizieren ist.
Diese Thesis ist eine Studie darüber, ob die Verwendung spezifischer „Baupläne“ (genannt Design Patterns) die Rust-Software verbessert. Der Autor, Leon Heuer, testete dies, indem er drei reale Softwarekomponenten eines deutschen Einzelhändlers (OTTO) nahm und diese unter Verwendung zweier spezifischer Baupläne neu aufbaute: dem Typestate Pattern und dem Newtype Pattern.
Hier ist eine einfache Aufschlüsselung dessen, was er herausfand, unter Verwendung von Alltagsanalogien:
1. Das Problem: Der „Spülbecken“-Code (Kitchen Sink Code)
Vor den Änderungen sah die Software aus wie ein riesiges Spülbecken, in das alles zusammengeschüttet wurde.
- Das Problem: Eine einzige Funktion versuchte alles zu erleden: prüfen, ob ein Benutzer eingeloggt ist, Daten abrufen, Zahlen validieren und Ergebnisse speichern. Sie war lang, verwirrend, und wenn man einen Teil änderte, konnte man versehentlich etwas ganz anderes in der Ferne beschädigt.
- Das Risiko: Es war leicht, Fehler zu machen, wie zum Beispiel zu versuchen, eine Tür zu öffnen, die noch nicht entriegelt wurde. Der Computer würde einen erst stoppen, wenn man das Programm tatsächlich ausführt und es abstürzt.
2. Die Lösung: Zwei neue Baupläne
Bauplan A: Der „Newtype“ (Der Ausweis)
Die Analogie: Stellen Sie sich vor, Sie haben eine Kiste mit gemischten Schlüsseln. Einige öffnen die Haustür, einige die Hintertür und einige sind nur dekorativ. Wenn Sie einen „Haustürschlüssel“ in das „Hinterturtür-Schloss“ stecken, passiert nichts, bis Sie ihn benutzen, und dann stecken Sie fest.
Die Lösung: Das Newtype Pattern ist wie das Anbringen eines deutlichen Etiketts auf jeden Schlüssel. Sie erstellen eine spezielle „Haustürschlüssel“-Box. Sie können nicht versehentlich einen „Hintertürschlüssel“ hineinlegen.
- Was geschah: Der Autor nahm rohen Text (wie eine Zeichenkette aus Zahlen) und hüllte ihn in eine spezielle „Validierte“-Box ein. Wenn der Text nicht gültig war, schloss sich die Box nicht.
- Das Ergebnis: Dies war ein riesiger Gewinn. Es war kostengünstig umzusetzen, machte den Code viel leichter lesbar und verhinderte, dass ungültige Daten jemals in das System gelangten. Es ist wie ein Sicherheitsmann an der Tür, der Ausweise prüft, bevor jemand eintritt.
Bauplan B: Der „Typestate“ (Das Fließband)
Die Analogie: Stellen Sie sich vor, Sie bauen ein Auto. Sie können das Auto nicht lackieren, bevor Sie das Fahrgestell gebaut haben, und Sie können den Motor nicht einbauen, bevor das Fahrgestell bereit ist. Im alten Code konnte ein Programmierer versehentlich versuchen, das Fahrgestell zu lackieren, bevor es existierte, und der Computer würde ihn erst stoppen, wenn die Lackierung fehlschlug.
Die Lösung: Das Typestate Pattern verwandelt den Code in ein striktes Fließband.
- Schritt 1: Sie beginnen mit einem Zustand namens „Rohes Fahrgestell“.
- Schritt 2: Sie können die Aktion „Motor einbauen“ nur ausführen, wenn Sie ein „Rohes Fahrgestell“ besitzen. Sob-mal Sie dies tun, verschwindet das Fahrgestell und wird zu einem „Fahrgestell mit Motor“.
- Schritt 3: Sie können nur „Lackieren“, wenn Sie ein „Fahrgestell mit Motor“ besitzen.
- Das Ergebnis: Der Computer verhindert physisch, dass Dinge in der falschen Reihenfolge getan werden. Wenn Sie versuchen, ein Fahrgestell zu lackieren, das noch nicht existiert, wird der Code nicht einmal kompilieren (er wird den Bau der Software verhindern).
- Der Kompromiss: Dies macht den Code unglaublich sicher und leicht testbar, fügt aber viel „Boilerplate“ hinzu (zusätzlichen Schreibaufwand). Es ist wie das Ausfüllen eines Formulars für jeden einzelnen Schritt am Fließband. Es ist sicherer, aber es bedeutet mehr Papierkram.
3. Die Erkenntnisse: Hat es funktioniert?
Der Autor testete diese Änderungen mit drei Methoden: Er ließ den Code laufen, um zu sehen, wie schnell er ist, nutzte automatisierte Werkzeuge, um die Komplexität zu zählen, und führte Interviews mit Experten für Programmierung durch.
- Geschwindigkeit: Die Änderungen haben die Software nicht verlangsamt. Der „zusätzliche Papierkram“ der neuen Baupläne geschah so schnell, dass der Computer ihn gar nicht bemerkte.
- Sicherheit (Fehlerfreiheit): Dies verbesserte sich massiv. Die neuen Baupläne machten es unmöglich, „ungültige Zustände“ zu erzeugen (wie ein Auto ohne Räder). Fehler, die früher während der Laufzeit der Software auftraten, werden nun abgefangen, noch bevor die Software überhaupt gebaut wird.
- Testbarkeit: Es wurde viel einfacher, den Code zu testen. Anstatt das ganze riesige Spülbecken zu testen, konnte man jeden kleinen Schritt des Fließbands einzeln testen.
- Lesbarkeit: Dies war gemischt.
- Der Newtype (Ausweis) machte die Dinge klarer.
- Der Typestate (Fließband) machte die Dinge sicherer, aber einige Experten fanden, dass der zusätzliche Code es auf den ersten Blick schwieriger lesbar machte. Sobald man jedoch das Muster verstanden hatte, war es tatsächlich einfacher, der Logik zu folgen.
4. Das Fazit
Die Studie kommt zu dem Schluss, dass:
- Newtype ein „No-Brainer“ ist. Es ist eine kleine Änderung, die große Vorteile in Bezug auf Sicherheit und Klarheit bietet. Man sollte es immer verwenden, wenn man Daten hat, die gültig sein müssen (wie eine E-Mail-Adresse oder einen Preis).
- Typestate ist leistungsstark, aber schwerfällig. Es eignet sich am besten, wenn man komplexe Regeln hat, bei denen die Reihenfolge der Operationen eine große Rolle spielt (wie ein mehrstufiger Bezahlvorgang). Wenn der Prozess einfach und geradlinig ist, ist der zusätzliche Code es vielleicht nicht wert.
Kurz gesagt: Die Verwendung dieser Muster in Rust ist wie der Übergang von einer unordentlichen Werkstatt zu einer Fabrik mit Sicherheitswächtern und einem strikten Fließband. Es erfordert etwas mehr Planung im Voraus, aber das Endprodukt ist viel schwerer zu beschädigen und viel einfacher zu reparieren.
Ertrinken Sie in Arbeiten in Ihrem Fachgebiet?
Erhalten Sie tägliche Digests der neuesten Arbeiten passend zu Ihren Forschungsbegriffen — mit technischen Zusammenfassungen, in Ihrer Sprache.