Swift wurde entwickelt, um die Lücke zwischen den Null-Kosten-Abstraktionen von C++ und der dynamischen Flexibilität von Objective-C zu überbrücken. Frühe Versionen basierten stark auf Klassenvererbung und virtuellen Methoden-Tabellen, doch die Einführung der protokoll-orientierten Programmierung in Swift 2.0 erforderte ein nuancierteres Dispatch-Modell. Das Compiler-Team entschied sich für einen hybriden Ansatz, bei dem Protokoll Anforderungen (Methoden, die im Protokollkörper deklariert sind) Zeugen-Tabellen für Laufzeit-Polymorphismus verwenden, während Methoden, die ausschließlich in Erweiterungen definiert sind, statisch aufgelöst werden. Diese Designentscheidung geht auf die Notwendigkeit zurück, retroaktive Modellierung und Werttypen zu unterstützen, ohne die Leistungsmerkmale des statischen Dispatchs zu opfern.
Entwickler nehmen häufig an, dass die Bereitstellung einer Methodenimplementierung in einer Protokollerweiterung ein "Standardverhalten" erzeugt, das konforme Typen polymorph überschreiben können. Allerdings dispatcht Swift Methoden in Erweiterungen statisch basierend auf dem Compile-Zeit-Typ der Referenz, nicht dem Laufzeit-Typ der Instanz. Bei der Verwendung von existenziellen Boxen (any Protocol) ist der Compile-Zeit-Typ der existenzielle Container selbst, was dazu führt, dass Aufrufe auf die Implementierung der Erweiterung aufgelöst werden, unabhängig von Überschreibungen in konkreten Typen. Dies erzeugt heimtückische Fehler, bei denen benutzerdefinierte Implementierungen in Unterklassen oder Strukturen stillschweigend in heterogenen Sammlungen umgangen werden.
Um echtes dynamisches Polymorphismus zu ermöglichen, muss die Methode als Protokoll Anforderung innerhalb der Protokoll-Deklaration selbst deklariert werden. Dies zwingt den Compiler, einen Zeugen-Tabelle-Eintrag für die Methode zuzuweisen, was es zur Laufzeit ermöglicht, die korrekte Implementierung über die Zeugen-Tabelle des Typs nachzuschlagen. Für leistungs-kritische Algorithmen, bei denen Polymorphismus nicht notwendig ist, sollten Methoden in Erweiterungen verbleiben, um dem Compiler die Möglichkeit zu geben, sie inline zu setzen oder andere statische Optimierungen durchzuführen. Swift 5.6+ führte die explizite any-Schlüsselwort-Syntax ein, um die Existenztyp-Übertragung sichtbarer zu machen, und dient als Erinnerung, dass Typinformationen verloren gehen und der statische Dispatch standardmäßig zur Erweiterung zurückkehrt.
protocol Drawable { func draw() // Anforderung: dynamischer Dispatch über Zeugen-Tabelle } extension Drawable { func draw() { print("Standard") } func render() { print("Statisches Rendern") } // Erweiterung: nur statischer Dispatch } struct Circle: Drawable { func draw() { print("Kreis") } func render() { print("Kreis rendern") } } let shape: any Drawable = Circle() shape.draw() // Gibt "Kreis" aus (dynamischer Dispatch) shape.render() // Gibt "Statisches Rendern" aus (statischer Dispatch - ignoriert die Version von Circle!)
Wir entwickelten eine Vektorgrafik-Engine, bei der verschiedene Formen dem RenderCommand-Protokoll entsprachen. Wir fügten zunächst eine generatePreview()-Methode ausschließlich innerhalb einer Protokollerweiterung hinzu, um allen Formen ein standardmäßig rasterisiertes Thumbnail bereitzustellen. Konkrete Typen wie BezierCurve und Polygon implementierten ihre eigenen optimierten generatePreview()-Methoden, die ihre spezifischen geometrischen Eigenschaften für eine scharfe Darstellung nutzten. Als wir diese Formen in einem [any RenderCommand]-Array speicherten, um die Rendering-Pipeline zu verarbeiten, stellten wir fest, dass der Aufruf von generatePreview() auf jedem Element dasselbe unscharfe Standardbild erzeugte, anstatt der benutzerdefinierten hochqualitativen Vorschauen.
Wir erwogen drei verschiedene Lösungen. Zunächst könnten wir generatePreview() in die Deklaration des RenderCommand-Protokolls als formale Anforderung verschieben. Dieser Ansatz würde dynamischen Dispatch über die Zeugen-Tabelle garantieren und die korrekte Methodenauflösung zur Laufzeit sicherstellen. Dies würde jedoch jede Form erfordern, die Methode in ihrer Konformität explizit zu deklarieren, obwohl wir durch die Beibehaltung der Standardimplementierung in der Erweiterung für Typen, die keine Anpassungen benötigten, den Boilerplate-Code reduzieren könnten.
Zweitens könnten wir unsere Pipeline umstrukturieren, um Generics mit einer Funktionssignatur wie func process<T: RenderCommand>(commands: [T]) anstelle von existenziellen [any RenderCommand] zu verwenden. Dies würde den statischen Dispatch zur korrekten Implementierung bewahren, da Swift Generics zur Compile-Zeit monomorphisiert und die Typinformationen beibehält. Der Nachteil war, dass wir keine heterogenen Formtypen (Mischung von BezierCurve und Polygon) in einem einzigen Array speichern konnten, ohne einen Typ-Übertragungs-Wrapper zu implementieren, was die Komplexität des Codes erheblich steigern würde.
Drittens könnten wir das Besucher-Muster implementieren, um Methodenaufrufe manuell an den entsprechenden konkreten Typ weiterzuleiten. Dies würde die vollständige Modifikation der Protokolldefinition vermeiden, während dennoch polymorphes Verhalten erreicht wird. Dieses Lösung führte jedoch zu erheblichem Boilerplate-Code und schuf eine Wartungsbelastung, wenn neue Formtypen zum System hinzugefügt wurden.
Letztendlich wählten wir die erste Lösung, da das Protokoll intern zu unserem Modul war und die Klarheit des polymorphen Verhaltens für die Richtigkeit der Rendering-Engine entscheidend war. Die Hinzufügung der Anforderung hatte vernachlässigbare Auswirkungen auf unsere Binärgröße, und der geringe Overhead des Zeugen-Tabellen-Indirektion war im Vergleich zu den Rendering-Berechnungen unauffällig. Nach der Implementierung dieser Änderung nutzte die Vorschau-Generierung korrekt die optimierte Implementierung jeder Form, wodurch die visuellen Artefakte aus der Benutzeroberfläche eliminiert wurden.
Warum kann eine Unterklasse eine Methode, die nur in einer Protokollerweiterung definiert ist, nicht überschreiben?
Wenn eine Methode ausschließlich in einer Protokollerweiterung und nicht im Protokoll selbst deklariert ist, weist Swift keinen Zeugen-Tabellen-Eintrag dafür zu. Der Dispatch wird zur Compile-Zeit basierend auf dem Bezugstyp aufgelöst. Wenn eine Klasse dem Protokoll entspricht und eine Methode mit derselben Signatur definiert, erstellt sie eine neue, nicht verwandte Methode, die die Methoden der Erweiterung verdeckt, anstatt sie zu überschreiben. Das bedeutet, dass, wenn über einen Protokoll-Existential (any Protocol) zugegriffen wird, die Implementierung der Protokollerweiterung immer aufgerufen wird und die Version der Klasse ignoriert wird. Um polymorphes Verhalten zu erreichen, muss die Methode in der Protokolldeklaration als Anforderung mit dynamischem Dispatch deklariert werden.
Wie beeinflusst die Verwendung von some (opake Ergebnistypen) im Vergleich zu any den Dispatch für Methoden von Protokollerweiterungen?
Mit some Drawable ist der konkrete Typ zur Compile-Zeit bekannt, da Swift Generics monomorphisiert. Wenn eine Erweiterungsmethode für einen opaken Typ aufgerufen wird, kann der Compiler statisch zum Implementierung des konkreten Typs dispatchen, da die Typinformationen hinter den Kulissen beibehalten werden, auch wenn sie für den Aufrufer verborgen sind. Im Gegensatz dazu ist any Drawable eine existenzielle Box, die den konkreten Typ verwischt, wodurch der Compiler gezwungen wird, die Standardimplementierung der Protokollerweiterung für Methoden ohne Anforderungen zu verwenden. Der entscheidende Unterschied ist, dass some statisches Polymorphismus beibehält, was es dem Compiler ermöglicht, inline zu setzen oder direkt an die richtige Methode zu binden, während any einen Laufzeit-vtable-Lookup nur für Anforderungen erzwingt und standardmäßig auf die Erweiterung für alles andere zurückkehrt.
Wie wirkt sich die Konvertierung einer Methoden in einer Erweiterung in eine Protokollanforderung auf die Binärgröße und Leistung aus?
Die Umwandlung einer Methoden in einer Erweiterung in eine Protokollanforderung fügt einen Eintrag zur Zeugen-Tabelle des Protokolls hinzu, wodurch sich die Binärgröße um etwa 8 Byte pro Konformität in 64-Bit-Architekturen erhöht. Jeder konforme Typ muss nun diesen Slot in seiner Zeugen-Tabelle ausfüllen, was einen kleinen Speicher-Overhead pro Typ hinzufügt. Leistungstechnisch verursachen Anforderungen einen indirekten Aufruf-Overhead durch die Zieltabelle (eine zusätzliche Zeiger-Dereferenzierung und Sprung), während Methoden in Erweiterungen inline gesetzt oder direkt ohne Overhead aufgerufen werden können. Der Verlust der Inlinesetzung für Anforderungen wird jedoch oft durch den CPU-Zweigvorhersager ausgeglichen, und der Vorteil des korrekten polymorphen Verhaltens überwiegt in der Regel die Nanosekunden-kosten des indirekten Aufrufs in den meisten Anwendungsprogrammen.