Manuela Rink Microsoft

Eine strenge Typisierung vermeidet bereits zur Kompilierzeit viele Fehler, die einen sonst später zur Laufzeit teurer zu stehen kommen würden.

Swift ist streng, was Typen angeht. Es ist nämlich eine statisch typisierte Sprache. Die Swift-Entwickler unter den Lesern haben bestimmt bereits die roten kleinen Kreise aus Xcode vor Augen – die Compilerfehler! Warum kommt es dazu, und weshalb hat man ab und an das Gefühl, Swift stehe bei der Entwicklung eher im Wege, anstatt den ohnehin schon steinigen Pfad in Richtung Ziel einfacher zu gestalten? Diese Fragen werden auf den folgenden Seiten durch einen Blick unter die Haube des Typsystems in Swift beantwortet.

Über die Zeit haben sich die eher losen Begriffe von „statischer vs. dynamischer“ bzw. „strenger vs. schwacher“ Typisierung rund um Programmiersprachen gefestigt. Aber was bedeuten sie denn nun genau? Alles dreht sich bei der Klassifizierung um Typen und darum, von welchem Typ Variablen und Konstanten sind. Doch im Grunde ist die Erklärung ganz einfach. Statisch typisierte Sprachen setzen bereits zur Kompilierzeit voraus, dass alle Typen definiert sind. Dynamisch typisierte Sprachen sind lockerer und überprüfen das erst zur Laufzeit. Nun haben beide Ansätze Vor- und Nachteile: gesunde Einschränkung vs. grenzenlose (Fehler-)Möglichkeiten?

Die statische Typisierung bewahrt den Entwickler und seine Anwendung bereits im Vorfeld vor mysteriösen Abstürzen und Fehlverhalten, frei nach dem Motto „fail fast, fail cheap“. Da man aber klar definieren muss, welcher Wert von welchem Typ ist, hat man als Entwickler oftmals das Gefühl der künstlichen Einschränkung. Es ist durchaus mühsam, bereits im Vorfeld für jeden verwendeten Wert den Typ festzulegen und im Programmablauf beispielsweise mit Typecasting sicherzustellen, dass er auch eingehalten wird.

Anders verhält es sich mit dynamischer Typisierung. Hier besteht nicht die Notwendigkeit, alle Typen zu kennen – man weist einfach Werte auf Variablen zu, ohne sich im Detail über die Typen im Klaren sein zu müssen. Das Verfassen von Quellcode ist so etwas freier, da man nicht ständig auf die Finger geklopft bekommt, wenn z. B. ein Float-Wert nicht mit einer StringVariable zusammenpasst. Erst, wenn das Programm ausgeführt wird, müssen die Werte und Typen kompatibel sein, was unter Umständen allerdings zu Fehlern und Abstürzen führen kann.

Swift zählt klar zu der Gruppe der statisch typisierten Sprachen, was Apple selbst „typsicher“ nennt. Der Entwickler soll sich sicher sein können, dass alle verwendeten Werte auch einen definierten Typ aufweisen – zu jeder Zeit. Somit hilft diese Art von Typsicherheit, Fehler im Programm frühestmöglich im Entwicklungsprozess zu finden, nämlich bereits da, wo der Code geschrieben und kompiliert wird. Dies soll wiederum Laufzeitfehlern jede Daseinsberechtigung entziehen.

Typbasierte Fehler, die sich während der Entwicklung bzw. noch beim Schreiben des Quellcodes einschleichen, werden in Xcode visuell anschaulich dargestellt. Das passiert in der Regel auch erstaunlich schnell. Kaum hat man z. B. einer Variable einen unpassenden Wert zugewiesen, wird man sofort durch ein Banner inklusive eines kleinen roten Punkts darauf hingewiesen. Fehler wollen eben schnell erkannt und beseitigt werden!

Hierarchie der Typen

Nun widmen wir uns der Basis, nämlich der Definition von Typen in Swift. Im Vergleich zu anderen, (teils) statisch typisierten Sprachen wie Java oder Objective-C gibt es hier feine, aber wesentliche Unterschiede, die im hierarchischen Aufbau der Typen begründet sind.

Den vollständigen Artikel lesen Sie in der Ausgabe:

Entwickler Magazin 2.18 - "Einstieg in Go"

Alle Infos zum Heft
579828468Ein Blick unter die Haube des Swift-Typsystems
X
- Gib Deinen Standort ein -
- or -