Event-driven Architektur auf Swift: Code in ein Ereignis-Orchester verwandeln

Online Python-Trainer für Anfänger

Lernen Sie Python einfach ohne theoretische Überlastung. Lösen Sie praktische Aufgaben mit automatischer Überprüfung und schreiben Sie Code direkt im Browser.

Kurs starten

Warum Ihre Swift-App eine event-driven Architektur braucht?



Stellen Sie sich vor, Sie sind der Dirigent eines Orchesters. Jeder Musiker wartet auf seinen Part, um im richtigen Moment einzusteigen. Wenn die Geiger alles auf einmal spielen würden, gäbe es Chaos. Ähnlich funktioniert die event-driven Architektur auf Swift: Jedes Modul reagiert nur auf bestimmte Ereignisse, anstatt andere Module direkt an den Fäden zu ziehen.



Als ich zum ersten Mal in einem kommerziellen Projekt auf ereignisorientierte Programmierung mit Swift gestoßen bin, habe ich verstanden, wie mächtig dieses Werkzeug ist. Eine App für die Essenslieferung: Der Benutzer drückt die Schaltfläche „Bestellen“ – das ist ein Ereignis. Der Warenkorb wird aktualisiert – ein Ereignis. Ein Push mit dem Kurier kommt – ein Ereignis. Jedes Modul (UI, Netzwerk, lokale DB) abonniert einfach die benötigten Ereignisse und arbeitet unabhängig. Das ist event-driven Architektur.



In diesem Artikel werden wir drei Ansätze zur Implementierung der Ereignisarchitektur in Swift behandeln: klassische Delegates, NotificationCenter und einen benutzerdefinierten Event-Bus. Sie sehen echten Code, verstehen, wann was verwendet wird, und können es sofort in Ihrem Projekt anwenden. Los geht's!



Grundlagen des event-driven Ansatzes in Swift



Was ist ein Ereignis im Kontext von Swift?



Ein Ereignis ist ein Signal, dass etwas passiert ist. Das kann sein:

  • Benutzereingabe (Schaltfläche gedrückt, Text geändert)
  • Datenänderung (Daten vom Server eingetroffen, DB aktualisiert)
  • Systembenachrichtigungen (App in den Hintergrund getreten, Tastatur erschienen)


Das Hauptprinzip der event-driven Architektur in Swift ist lose Kopplung (loose coupling). Der Absender eines Ereignisses weiß nicht, wer es verarbeitet. Der Empfänger weiß nicht, wer es gesendet hat. Sie kommunizieren über einen Event-Bus – das macht den Code flexibel und testbar.



Das Observer-Pattern – Fundament der Ereignisse



Das Observer-Pattern in Swift liegt jeder event-driven System zugrunde. Wir haben ein Publisher-Objekt und viele Subscriber. Wenn der Publisher seinen Zustand ändert, benachrichtigt er alle Subscriber.



In Swift gibt es mehrere eingebaute Mechanismen dafür:

  • NotificationCenter – globaler Event-Bus im iOS SDK
  • Delegates – eins-zu-eins, aber mit Kontrolle
  • Combine – reaktives Framework von Apple (iOS 13+)
  • Benutzerdefinierte Implementierungen – volle Kontrolle über das Verhalten


Lassen Sie uns jeden Ansatz mit Beispielen durchgehen.



Methode 1. Delegates: Klassiker der Branche



Delegates in Swift sind der einfachste Weg, ein Ereignis zu implementieren. Sie eignen sich für Eins-zu-eins-Beziehungen, wenn ein Objekt einem anderen seinen Zustand mitteilt.



Beispiel: Stellen Sie sich vor, wir haben einen Bildlader, der den Controller über den Abschluss benachrichtigen muss.



// 1. Definieren des Delegate-Protokollsprotocol ImageLoaderDelegate: AnyObject {    func imageLoader(_ loader: ImageLoader, didLoad image: UIImage)    func imageLoader(_ loader: ImageLoader, didFailWith error: Error)}

// 2. Publisher-Klasseclass ImageLoader { weak var delegate: ImageLoaderDelegate?

func loadImage(from url: URL) { URLSession.shared.dataTask(with: url) { [weak self] data, _, error in DispatchQueue.main.async { if let error = error { self?.delegate?.imageLoader(self!, didFailWith: error) } else if let data = data, let image = UIImage(data: data) { self?.delegate?.imageLoader(self!, didLoad: image) } } }.resume() }}

// 3. Subscriber-Controllerclass ViewController: UIViewController, ImageLoaderDelegate { let loader = ImageLoader() @IBOutlet weak var imageView: UIImageView!

override func viewDidLoad() { super.viewDidLoad() lo

Blogs

Buchempfehlungen