Generics, Tuples, Namespaces, Closures... Programmierparadigmen, die bisher mit Objective-C nicht denkbar sind. Apple hat gestern
zur Überraschung der Entwicklergemeinde eine neue und moderne Programmiersprache vorgestellt, die das betagte Objective-C ablösen soll.
Entwicklung von Objective-CDie erste Version von Objective-C war eine sehr schlanke objektorientierte Erweiterung von C und brachte wenige direkte Sprachfunktionen mit. Von vielen wurde dies bejubelt, da dies die Verständlichkeit des Codes stark steigerte - andere vermissten bekannte Programmierparadigmen aus anderen Sprachen.
Apple führte zur WWDC 2006 eine Erweiterung von Objective-C ein (genannt Objective-C 2.0). Neu waren unter anderem Properties (Punkt-Notation beim Zugriff auf Instanz-Variablen von Objekten, beispielsweise meinObjekt.wert=5 statt [meinObjekt setWert:5]), verbessertes Durchlaufen von Objekt-Sammlungen sowie Code-Blöcke.
Auch wurde der Objective-C-Garbage-Collector eingeführt, so dass sich Entwickler nicht mehr selbst um die Speicherverwaltung kümmern mussten. Zur Laufzeit des Programmes analysierte der Garbage Collector, ob ein Speicherbereich noch benötigt wird oder nicht. Leider war dies sehr leistungsintensiv und fehleranfällig, weswegen Apple diese Technologie nicht weiter verfolgen konnte. Daher führte Apple mit OS X 10.8 eine Code-Analyse namens ARC (Automatic Reference Counting) ein, die beim Kompilieren bereits analysiert, wann welche Speicherbereiche nicht mehr benötigt werden. Mit ARC liegt es nicht mehr in der Verantwortung des Entwicklers, Speicher für Objekte wieder freizugeben.
Cocoa & Cocoa TouchOS-X- und iOS-Entwicklern stehen mit Cocoa und Cocoa Touch mächtige Frameworks zur Verfügung. Die gute Nachricht ist, dass sich diese Frameworks auch aus Swift heraus vollständig nutzen lassen. Umsteiger von Objective-C müssen also nicht bei Stunde Null anfangen, sondern nur eine neue Syntax lernen.
Ein Blick auf Swift, Apples neue ProgrammierspracheDie Syntax erinnert an eine Mischung aus verschiedenen anderen objektorientierten Sprachen wie C# und Java. Es wird auf explizite Header-Dateien verzichtet, die Definition einer Klasse und die Implementierung finden sich in der selben Datei wieder (mit der Endung .swift). Eine gewöhnliche Klasse sieht wie folgt aus:
class Shape {
var numberOfSides = 0
func simpleDescription() -> String {
return "A shape with \(numberOfSides) sides."
}
}
Dies definiert die Klasse namens "Shape", die eine Instanz-Variable mit dem Namen numberOfSides mitbringt. Ferner wird eine Funktion definitiert (simpleDescription), die eine Zeichenkette mit der Seiten zurückliefert. Rückgabewerte werden mit "- >" gekennzeichnet (in diesem Fall ein String), in den Klammern nach dem Funktionsnamen können benannte Parameter übergeben werden (die Funktion simpleDescription hat in diesem Fall keine). Eine gute Entscheidung von Apple war die Beibehaltung von benannten Parameternamen bei Funktionen - dies erhöht die Lesbarkeit und die Verständlichkeit von Code deutlich.
Etwas gewöhnungsbedüftig ist, dass Variablen zwar typisiert sind, dies aber nicht in allen Fällen explizit angegeben werden muss. So kann beispielsweise eine Ganzzahl (in Swift auch ein Objekt, anders als in Objective-C) in einer Variable gespeichert werden, ohne explizit angegeben zu müssen, dass die Variable eine Ganzzahl sein soll:
var meinInt = 60
Der Compiler erkennt, dass 60 ein Ganzzahl ist und weist meinInt automatisch diesen Typ zu. Glücklicherweise ist es aber auch möglich, durch einen Doppelpunkt explizit anzugeben, um welchen Typ es sich handelt:
var meinInt: Int = 60
Die Behandlung von Variablen, die entweder einen Verweis auf eine Klasseninstanz oder explizit auf kein Objekt zeigen, ist in Swift zwar sicher gelöst, aber umständlich zu nutzen ("Optional Chaining"). Mittels Fragezeichen lassen sich Variablen als Optional markieren, hier muss der Programmierer damit rechnen, dass diese auch nicht zugewiesen sein können. Will man beispielsweise auf die optionale Variable "meineVar" im Objekt nach "meinObjekt" nach "datum" fragen (meineVar ist Optional), hilft folgender code weiter:
if let meinDatum = meinObjekt.meineVar?.datum {
println("Das Datum ist \(meinDatum).")
}
Nur wenn in meinObjekt die Variable meineVar gesetzt ist, bekommt die Konstante meinDatum einen Wert und der Code in der If-Bedingung wird überhaupt ausgeführt.
Komplexität von SwiftViele weitere Sprachkonstrukte wie Beispielsweise Tuples (Variablen, die mehrere Werte beinhalten können; besonders bei Rückgabewerten von Vorteil), Subscripts (der schnelle Zugriff auf Objektsammlung mittels eckiger Klammern) und deutlich flexiblere Enums sind sehr sinnvolle Bestandteile von Swift - führen aber auch zu Problemen. Die Komplexität der Sprache ist besonders im Vergleich zu der ersten Objective-C-Version enorm gestiegen. Gab es in Objective-C meist nur wenige sprachliche Möglichkeiten, bietet Swift mehrere, teils redundante Ansätze zur Problemlösung. Besonders bei der Zusammenarbeit in Entwickler-Teams kann dies zu Konflikten führen, wenn die Entwickler verschiedene Code-Stile verwenden.
Erst in den kommenden Monaten und Jahren wird sich zeigen, ob Swift das sehr bewährte Objective-C ablösen kann. Objective-C hat sich selbst bei sehr großen Projekten bewährt, diese wartbar und verständlich zu halten. Die Anforderungen an Swift sind enorm: Moderne Sprachfeatures unterstützen, grundsätzlich kompatibel mit Objective-C bleiben, weiterhin die Zusammenarbeit mit C-Programmierbibliotheken zu ermöglichen und bei großen Projekten die Übersichtlichkeit des Codes zu gewährleisten.
Migration und Integration von bestehendem ProgrammiercodeApple hebt in der Dokumentation zu Swift deutlich hervor, dass sich Swift-Code gut mit Objective-C und C mischen lässt. Zwar ist es nicht möglich, aus Objective-C heraus die modernen Sprachfunktionen von Swift zu nutzen, aber es ist möglich, Swift-Klassen von Objective-C abzuleiten und Funktionen in beide Richtungen aufzurufen. Auch kann der Entwickler mit C-Programmierschnittstellen interagieren, dies ist aber deutlich mühseliger und unübersichtlicher als in Objective-C. So soll es möglich sein, größere Objective-C-Projekte nach und nach auf Swift umzustellen, ohne das man das gesamte Projekt auf einmal neu programmieren muss. Sobald die ersten Entwickler anfangen, Teile von größeren Projekten auf Swift umzustellen, wird sich zeigen, ob der von Apple vorgeschlagene Weg sich tatsächlich in der Praxis bewährt.
Umstieg auf SwiftViele Entwickler dürften sich die Frage stellen, ob es sinnvoll ist, ein neues Projekt jetzt in Swift oder in Objective-C zu beginnen. Swift ist gerade erst auf den Markt gekommen und wird mit Sicherheit noch einige Fehler aufweisen und diverse Probleme bei dem Umgang mit den bestehenden Cocoa- und Cocoa-Touch-Frameworks bereiten. Wenn das Projekt eine Laufzeit von weniger als drei Jahren haben soll, bevor eine Neuentwicklung ansteht, wird der Entwickler mit Objective-C besser beraten sein. Soll die Code-Basis länger als drei Jahre eingesetzt werden, könnte der Wechsel zu Swift sinnvoll sein. Apple schweigt sich momentan noch darüber aus, wann neue Programmierschnittstellen nicht mehr für Objective-C, sondern nur noch für Swift zur Verfügung stehen.
Weiterführende Links: