Warum Views typischerweise auf Structures und nicht auf Klassen basieren
Zusammen mit Xcode 11 wurden auch Swift 5.1 und das neue SwiftUI-Framework in einer ersten finalen Version veröffentlicht. Vorbei sind somit die Zeiten des ausgiebigen Beta-Testens, jetzt geht es in Sachen SwiftUI endlich ans Eingemachte (auch hier auf dem Blog). 🙂
Anstatt aber mit einer neuen Tutorial-Serie zu beginnen oder an dieser Stelle über Best Practices zu schreiben, möchte ich zunächst einmal ein anderes Thema ansprechen. Es ist ein Detail, mit dem man umgehend in Berührung kommt, wenn man eine erste eigene View auf Basis des SwiftUI-Frameworks erstellt und das sich stark von dem unterscheidet, was man bisher als Apple Developer gewohnt ist.
Es geht um die Frage, warum Views in SwiftUI primär auf Structures und nicht auf Klassen basieren.
SwiftUI und die Macht der Structures
Wer die Entwicklung von Swift verfolgt und den Entwicklern bei Apple in WWDC-Lessons ausgiebig lauscht, dürfte schon in den letzten Jahren gemerkt haben, dass Structures in Swift eine enorm wichtige Rolle spielen. Tatsächlich fährt Apple hier den Grundsatz, das man prinzipiell neue Typen lieber (erst einmal) auf Basis einer Structure als einer Klasse erstellen sollte (es sei denn es ist von vornherein klar, dass in zwingend die Funktionalität einer Klasse benötigt wird).
Dass das so betont werden muss, ist für langjährige Apple Developer kein Wunder. Schließlich arbeitete man unter Objective-C primär und ausschließlich mit Klassen. Die ganze Struktur und der Aufbau von Frameworks wie UIKit und AppKit ist auf Klassen aufgebaut. Entsprechend arbeitet man auch unter Swift so gesehen in der Regel mit Klassen, und sei es rein aus Gewohnheit.
Structures haben aber durchaus ihre Vorteile, und gerade die spielt Apple mit SwiftUI auch voll aus. Allen voran geht es um einen einfachen Fakt: sie sind leichtgewichtig. Da Structures keine Vererbung unterstützen, verfügt jede Structure nur über die Eigenschaften und Funktionen, die in ihr implementiert sind.
Erstellt man so also eine View auf Basis von SwiftUI und einer Structure, definiert die Structure allein alle Eigenschaften und Funktionen, die für diese View relevant sind. Eigenschaften, die nicht benötigt werden und nicht relevant sind, existierten schlicht nicht.
Man vergleiche das mit dem Erstellen einer View auf Basis von UIKit und der Klasse UIView. Eine einfache Subklasse von UIView verfügt bereits über eine Vielzahl an Eigenschaften und Funktionen wie Farben oder Alpha-Werte, die womöglich in der Praxis niemals für die Subklasse relevant sind. Aber sie sind da und stehen zur Verfügung, ob man sie braucht oder nicht.
Das Prinzip der Einfachheit
Darüber hinaus macht das gesamte Konzept von SwiftUI den Einsatz von Structures sinnvoll. Beispiel Datenhaltung: Dank Binding werden Views automatisch aktualisiert, wenn sich Daten und damit Teile einer View verändern. Dazu können der alte Stand und der neue Stand einer View schlicht miteinander verglichen und die Parts, die sich geändert haben, neu gezeichnet werden.
Es braucht hier also kein bisweilen aufwendiges Referenzmanagement. Views sollen einfache, leichtgewichtige Instanzen sein, die Informationen darstellen und für den Nutzer greifbar machen. Structures sind dafür ideal geeignet.
Für mich stellt sich hier abschließend viel eher die Frage, ob SwiftUI aus diesem Prinzip der Einfachheit heraus auch wirklich imstande ist, selbst komplexe Views gut abzubilden. Das ist allerdings eine Frage, die ich persönlich zum jetzigen Zeitpunkt noch nicht beantworten kann; dazu muss SwiftUI erst noch sehr sehr ausführlich getestet werden.
Euer Thomas
Schreibe einen Kommentar