Structures und Klassen besitzen in Swift viele Gemeinsamkeiten. Das macht gerade Structures im Vergleich zu anderen Programmiersprachen sehr besonders. Sie können in Swift zum Beispiel Stored und Computed Properties sowie Methoden besitzen; Eigenschaften, über die Structures in anderen Programmiersprachen in der Regel nicht verfügen (und sie daher für diese Sprachen nur eingeschränkt nutzbar machen).
Nicht so aber in Swift. Generell fallen bei der täglichen Programmierung in vielen Situationen kaum Unterschiede zwischen Structures und Klassen auf. Entsprechend stellt sich die Frage, wann man eher eine Structure und wann eine Klasse einsetzen sollte.
Apple hat dazu einen eigenen Artikel auf der Developer-Website veröffentlicht (den Link findet ihr auch noch einmal am Ende des Artikels). Auf dessen Basis möchte ich euch einen Überblick geben, wann Structures und wann Klassen sinnvoll sind und wie ihr generell bei der Programmierung mit Swift am besten vorgehen solltet.
Structures als Standard
Geht es nach Apple, stellen Structures typischerweise den Standard bei der Erstellung neuer Typen dar. Aufgrund ihrer Funktionsvielfalt können sie für fast alle Aufgaben eingesetzt werden, für die man ansonsten eigentlich auf Klassen zurückgreifen würde. Dazu gehören unter anderem die bereits genannte Möglichkeit zur Implementierung von Properties und Methoden.
Structures in Swift können aber auch Protokolle adaptieren. Das erlaubt es, eine Datenstruktur auf Basis von Protokollen in Swift zu kreieren und diese Protokolle anschließend mithilfe von Structures zu implementieren. Klassen sind für solche Aufgaben in Swift nicht zwingend notwendig.
Identity und Objective-C
Hingegen sollten Klassen die erste Wahl sein, wenn ihr mit Objective-C-Code zusammenarbeiten möchtet oder die Identität von Instanzen eine essenzielle Rolle spielt. Doch was heißt das genau?
Viele Frameworks von Apple basieren zum großen Teil auf Objective-C, beispielsweise UIKit oder AppKit. Entsprechend viele Klassen finden sich in diesen Frameworks, was meist dazu führt, dass ihr ebenfalls mit Klassen in Swift arbeiten müsst, möchtet ihr das entsprechende Framework nutzen. Auch in Projekten mit eigens erstellten Objective-C-Klassen werdet ihr für ein reibungsloses Zusammenspiel auf Swift-Seite ebenfalls Klassen einsetzen müssen.
Das Thema Identität ist relevant, wenn ihr Instanzen eines Typs nicht nur aufgrund ihres Werts, sondern auf Basis ihrer Speicheradresse identifizieren müsst (hierfür kommt der ===-Operator zum Einsatz). Da die hierfür benötigten Reference Types in Swift ausschließlich durch Klassen repräsentiert werden, kommt ihr in diesem Kontext also ebenfalls nicht um den Einsatz von Klassen herum.
Ein häufiges Szenario in diesem Zusammenhang sind Singletons, von denen es de facto nur eine einzige Instanz innerhalb eines Projekts geben soll die von überall referenziert wird.
Tipp: Data Modelling mit Protokollen
Zum Abschluss noch ein Hinweis in Bezug auf den bevorzugten Einsatz von Structures: Mithilfe von Protokollen könnt ihr eine abgewandelte Form der Vererbung auch in Structures umsetzen, da Protokolle ebenfalls – genau wie Klassen – voneinander erben können. Das könnt ihr euch zunutze machen, um eine Model-Hierarchie auf Basis von Protokollen und Structures umzusetzen, wie sie ansonsten nur mithilfe von Klassen möglich wäre.
Das beste Vorgehen hierbei besteht darin, zunächst die gewünschten Protokolle mitsamt deren Eigenschaften und Funktionen zu erstellen. Auf Basis dieser Grundlage kreiert ihr dann Schritt für Schritt die zugehörige Implementierung auf Basis von Structures.
Fazit
Structures sind in der Regel das bevorzugte Mittel der Wahl zum Erstellen komplexer Typen in Swift. Das mag ungewohnt sein, wenn man zuvor mit Objective-C programmiert hat, spiegelt aber die Best Practices in Swift wider. Klassen sollten so tatsächlich nur dann zum Einsatz kommen wenn es gar nicht anders geht. Entsprechende Szenarien sind das Zusammenspiel mit Objective-C-API oder die Notwendigkeit, über die genau Identität einer Instanz Bescheid zu wissen.
Wenn ihr also zukünftig an einem Projekt arbeitet, versucht doch einmal den von Apple präferierten Ansatz und strukturiert euren Code mittels Protokollen und Structures. Dass ist der für Swift typische Weg. 🙂
Euer Thomas
Weiterführende Links zum Artikel
- Artikel „Choosing Between Structures and Classes“ auf der Apple Developer-Website: https://developer.apple.com/documentation/swift/choosing_between_structures_and_classes
Schreibe einen Kommentar