Beitrag erstellt am: 15.10.20
Nachstehend ein paar Gedanken zum Thema Domänentypen - mehr eine Ideenskizze denn konkrete Handlungsanweisung:
Im Kontext von "Secure by Design" sind ausdrucksstarke Domänentypen ein wichtiges Element. Sie erhöhen nicht nur die Robustheit unserer Entwürfe, sie helfen uns auch dabei, leckgeschlagene Abstraktionen (vgl. Joel Spolsky zum Thema "The Law of Leaky Abstractions") zu verhindern. Jedenfalls besser, als dies nur mit Omnitypes möglich ist. Sie zwingen uns nämlich dazu, sorgfältig darüber nachzudenken, ob Argumente und Rückgabewerte von Funktionen zur Abstraktionsebene der Funktionsnutzer passt. Siedersleben weist auf diesen Punkt im Zusammenhang mit der Unterscheidung von Fehlern und Ausnahmen hin: Passt ein abnormes Ergebnis als Rückgabewert zur Abstraktionsebene des Aufrufers, dann handelt es sich um einen Fehler, um die sich der Nutzer der Funktion kümmern kann und muss, wenn nicht, handelt es sich definitiv um eine Ausnahme.
Es gibt zahlreiche Beispiele für Domänentypen, die ihren auf Omnitypes basierenden Gegenparts überlegen sind:
Es spricht einiges dafür, anstelle von Omnitypes auf Domänentypen zu setzen und den Antimustern "Primitive Obsession" und "String-basierte Entwicklung" die kalte Schulter zu zeigen.
Im Kontext von Softwarekategorien und den Prinzipien des Domain-driven Designs gehören die Domänentypen zu einem fachlich abgegrenzten Kontext und sind Teil der allgegenwärtigen Sprache.
Mehr dazu wohl in einem späteren Beitrag.
Im Kontext von "Secure by Design" sind ausdrucksstarke Domänentypen ein wichtiges Element. Sie erhöhen nicht nur die Robustheit unserer Entwürfe, sie helfen uns auch dabei, leckgeschlagene Abstraktionen (vgl. Joel Spolsky zum Thema "The Law of Leaky Abstractions") zu verhindern. Jedenfalls besser, als dies nur mit Omnitypes möglich ist. Sie zwingen uns nämlich dazu, sorgfältig darüber nachzudenken, ob Argumente und Rückgabewerte von Funktionen zur Abstraktionsebene der Funktionsnutzer passt. Siedersleben weist auf diesen Punkt im Zusammenhang mit der Unterscheidung von Fehlern und Ausnahmen hin: Passt ein abnormes Ergebnis als Rückgabewert zur Abstraktionsebene des Aufrufers, dann handelt es sich um einen Fehler, um die sich der Nutzer der Funktion kümmern kann und muss, wenn nicht, handelt es sich definitiv um eine Ausnahme.
Es gibt zahlreiche Beispiele für Domänentypen, die ihren auf Omnitypes basierenden Gegenparts überlegen sind:
- Eine Mengenangabe, die nur positive Werte erlaubt, anstelle eines unqualifizierten Integer-Werts, um negative Mengenangaben zu verhindern.
- Ein Benutzername anstelle eines unqualifizierten String-Wertes. Dies erlaubt es bereits bei der Erzeugung des Domänentyps ungültige Zeichen zu filtern oder mit einem Fehler zurückzuweisen.
- Die Unterscheidung bei einem Backofen einer Garguttemperatur von einer Garraumtemperatur mit je
eigenen Wertbereichen und insbesondere auch mit der Möglichkeit zu verhindern, dass wir die beiden Temperaturtypen unbedacht in Berechnungen vermengen; all dies kann eine
unqualifizierte Fliesskommazahl oder ein Integer-Wert nicht leisten.
Es spricht einiges dafür, anstelle von Omnitypes auf Domänentypen zu setzen und den Antimustern "Primitive Obsession" und "String-basierte Entwicklung" die kalte Schulter zu zeigen.
Im Kontext von Softwarekategorien und den Prinzipien des Domain-driven Designs gehören die Domänentypen zu einem fachlich abgegrenzten Kontext und sind Teil der allgegenwärtigen Sprache.
Mehr dazu wohl in einem späteren Beitrag.