SOLID-Prinzipien in Swift: Theorie und Praxis von A bis Z

Einleitung: Warum SOLID das Fundament für qualitativ hochwertigen Swift-Code ist

Jeder iOS/macOS-Entwickler stößt früher oder später auf die Situation, dass der Code zu "Spaghetti" wird: Änderungen an einer Stelle bringen die gesamte Anwendung zum Absturz, und das Testen wird zum Albtraum. Genau hier kommen die SOLID-Prinzipien ins Spiel – fünf grundlegende Regeln des objektorientierten Designs, formuliert von Robert Martin.

In diesem Artikel analysieren wir jedes SOLID-Prinzip anhand von Swift-Beispielen, zeigen, wie deren Verletzung zu Problemen führt, und geben fertige Lösungen. Sie lernen, Code zu schreiben, der leicht zu warten, zu erweitern und zu testen ist.

1. Single Responsibility Principle (SRP) – Prinzip der einzigen Verantwortung

Theorie

SRP besagt: Eine Klasse sollte nur einen einzigen Grund für eine Änderung haben. Mit anderen Worten, jede Klasse ist für genau eine Funktionalität verantwortlich.

Verletzung des SRP (schlechter Code)

class UserManager {    func createUser(name: String, email: String) {        // Benutzer erstellen        saveToDatabase(user: User(name: name, email: email))        sendWelcomeEmail(to: email)        logEvent("Benutzer erstellt: \\(name)")    }        private func saveToDatabase(user: User) { /* ... */ }    private func sendWelcomeEmail(to email: String) { /* ... */ }    private func logEvent(_ message: String) { /* ... */ }}

Hier ist UserManager für das Erstellen, Speichern, Senden von E-Mails und das Loggen verantwortlich – vier Gründe für eine Änderung.

Korrektur (guter Code)

class UserService {    private let repository: UserRepository    private let emailService: EmailService    private let logger: Logger        init(repository: UserRepository, emailService: EmailService, logger: Logger) {        self.repository = repository        self.emailService = emailService        self.logger = logger    }        func createUser(name: String, email: String) {        let user = User(name: name, email: email)        repository.save(user)        emailService.sendWelcome(to: email)        logger.log("Benutzer erstellt: \\(name)")    }}

class UserRepository {    func save(_ user: User) { /* nur speichern */ }}class EmailService {    func sendWelcome(to email: String) { /* nur senden */ }}class Logger {    func log(_ message: String) { /* nur loggen */ }}

Jetzt hat jede Klasse eine einzige Verantwortung, was das Testen und die Wartung erleichtert.

2. Open/Closed Principle (OCP) – Prinzip der Offenheit/Geschlossenheit

Theorie

Klassen sollten offen für Erweiterung, aber geschlossen für Änderung sein. Neue Funktionalität wird durch Vererbung oder Protokolle hinzugefügt, ohne den vorhandenen Code zu verändern.

Verletzung des OCP

class PaymentProcessor {    func process(payment: Any, type: String) {        if type == "card" {            // Kartenverarbeitung        } else if type == "paypal" {            // PayPal-Verarbeitung        } // Beim Hinzufügen eines neuen Typs wird diese Klasse geändert    }}

Korrektur durch Protokolle

protocol PaymentMethod {    func process(amount: Double)}

class CardPayment: PaymentMethod {    func process(amount: Double) { /* Kartenverarbeitung */ }}

class PayPalPayment: PaymentMethod {    func process(amount: Double) { /* PayPal-Verarbeitung */ }}

class PaymentProcessor {    func process(payment: PaymentMethod, amount: Double) {        payment.process(amount: amount)    }}

// Neuen Typ hinzufügen, ohne vorhandenen Code zu ändernclass ApplePayPayment: PaymentMethod {    func process(amount: Double) { /* Apple Pay-Verarbeitung */ }}

Jetzt reicht es aus, eine neue Klasse zu erstellen, die das Protokoll PaymentMethod implementiert, um eine neue Zahlungsmethode hinzuzufügen.

3.