Einfache Datentypen mit Objective-C
Heute geht‘s mal wieder darum zu zeigen, dass sich die Beschäftigung mit funktionaler Programmierung auch dann lohnt, wenn man oft in imperativen oder objektorientierten Sprache unterwegs ist. Der Artikel zeigt anhand eines Beispiels aus der Praxis, wie wir in einer in Objective-C geschriebenen iOS-App Einflüsse aus der funktionalen Programmierung aufgenommen und damit eine sehr einfache Datenmodellierung ermöglicht haben. Wenn Sie selbst auch mit Objective-C programmieren, können Sie unsere Ergebnisse direkt nutzen, denn sie stehen auf github unter einer Open-Source-Lizenz zur Verfügung. Die Idee kann natürlich auch ohne weiteres für andere objektorientierte Sprache wie z.B. Java umgesetzt werden.
Datenmodellierung in funktionalen Sprachen ist sehr einfach: man definiert auf ganz natürliche Art und Weise einen oder mehrere Datentypen mit den gewünschten Feldern, falls nötig kann man auch für einen Datentypen mehrere Alternativen festlegen. Betrachten wir als Beispiel eine einfache Modellierung eines Telefonbuch-Eintrags in Haskell. Der Einfachheit halber verzichten wir in diesem Beispiel auf Datentypen mit Alternativen.
Einfach, oder? Der deriving (Show, Eq, Ord)
Teil sorgt dafür, dass der Compiler
automatisch Funktionen zur Umwandlung eines Wert des Datentypens in einen
String (show
) und zum Test auf Gleichheit (==
) generiert. Eine weitere
schöne Eigenschaft der obigen Datentypen ist, dass alle Werte automatisch
unveränderbar sind. (Auf englisch heißt das dann „immutable“. Auch die
objektorientierten Programmieren wissen diese Eigenschaften zu schätzen,
wie etwa Joshua Bloch in seinem Buchklassiker „Effective Java“ demonstriert.)
Was müssen wir tun, um dieselbe Funktionalität in einer objektorientieren Sprache
wie Objective-C zu implementieren? Hier ist meine Version, dabei verzichte
ich auf Hinschreiben der Implementierung von Address
.
Verdammt viel Code, oder? Die vergleichbare Implementierung in Java wäre nicht wesentlich kürzer.
Solche Art von Boilerplate-Code hat mehrere Nachteile. Man verschwendet viel
Zeit um den Code hinzuschreiben, was unserer Erfahrung nach häufig zu einer unsauberen
Datenmodellierung führt. Wir haben nämlich festgestellt, dass wir in unseren iOS-Projekt
aus Gründen der Zeitersparnis häufig darauf verzichten die einzelnen Properties
nach außen hin nicht schreibbar zu machen, dass wir isEqual:
und hashCode
nicht
überschreiben, oder dass wir keine sinnvolle description
Methode implementieren.
Da solche „Schlampigkeiten“ früher oder später zu Problemen führen, haben wir ein kleines Codegenerierungsskript geschrieben, welches uns das Schreiben des ganzen Boilerplate-Codes abnimmt. Mit dieser Codegenerierung reduziert sich das obige Beispiel auf folgende Zeilen, der Rest wird generiert.
Einfach, oder?
Diese Codegenerierung steht auch der Öffentlichkeit zur Verfügung, und zwar als github Repository. Dort wird auch erklärt, wie Sie die Codegenerierung in ihr Projekt einbinden.