Classes, Werttypen und Referenztypen

Das Problem: Ein überraschendes Verhalten

Probier diesen Code im Playground aus:

struct Counter {
    var count = 0
}

var a = Counter()
var b = a
b.count = 10

print(a.count)   // ?
print(b.count)   // ?

Die Antwort: a.count ist 0, b.count ist 10. Bei var b = a hat Swift eine Kopie angelegt. a und b sind zwei völlig unabhängige Zähler.

Jetzt ändere nur ein einziges Wort, struct wird zu class:

class Counter {
    var count = 0
}

let a = Counter()
let b = a
b.count = 10

print(a.count)   // 10 (!)
print(b.count)   // 10

Plötzlich ist auch a.count gleich 10, obwohl du a nie angefasst hast. Und noch seltsamer: Es funktioniert sogar mit let.

Was ist hier los? Genau darum geht es in dieser Lektion. Es ist eines der wichtigsten Konzepte in Swift, und in SwiftUI wirst du es ständig brauchen.

Werttypen und Referenztypen

Swift unterscheidet zwei Arten von Typen:

Das Bild mit dem Papier

Ein Werttyp ist wie ein Blatt Papier. Gibst du jemandem eine Fotokopie, kann er darauf herumkritzeln, wie er will. Dein Original bleibt unverändert.

Das Bild mit der Adresse

Ein Referenztyp ist wie ein Haus. Du gibst niemandem das Haus selbst, sondern einen Zettel mit der Adresse. Gibst du den Zettel weiter, hat der andere eine Kopie des Zettels, aber beide Zettel führen zum selben Haus. Streicht er die Haustür rot an, ist sie auch für dich rot.

Struct:   a ──▶ [count: 0]       b ──▶ [count: 10]     zwei Kopien

Class:    a ──┐
              ├──▶ [count: 10]                          ein Objekt, zwei Verweise
          b ──┘

Deshalb funktioniert bei der Klasse auch let: let bedeutet, dass der Zettel nicht ausgetauscht werden darf. a zeigt für immer auf dasselbe Haus. Was im Haus passiert, ist davon nicht betroffen.

Eine Klasse definieren

Klassen sehen Structs sehr ähnlich, mit einem wichtigen Unterschied: Sie haben keinen automatischen Initializer. Du musst ihn selbst schreiben:

class Player {
    var name: String
    var score: Int

    init(name: String, score: Int = 0) {
        self.name = name
        self.score = score
    }

    func addPoints(_ points: Int) {
        score += points
    }
}

let player = Player(name: "Anna")
player.addPoints(10)
print(player.score)   // 10

Drei Dinge fallen auf:

• init ist der Initializer. Er muss jeder Eigenschaft ohne Standardwert einen Wert geben.
• self.name = name: Parameter und Eigenschaft heißen gleich. self.name meint die Eigenschaft, name allein den Parameter.
• Methoden, die etwas ändern, brauchen kein mutating. Bei Klassen ändert man ja nicht den Zettel, sondern das Haus.

Wo das wichtig wird

Funktionen und Werttypen

struct Score {
    var points = 0
}

func reset(_ score: Score) {
    var copy = score
    copy.points = 0      // ändert nur die Kopie
}

Gibst du eine Struct an eine Funktion, bekommt die Funktion eine Kopie. Sie kann dein Original nicht versehentlich verändern.

Funktionen und Referenztypen

func reset(_ player: Player) {
    player.score = 0     // ändert das Original!
}

let anna = Player(name: "Anna", score: 50)
reset(anna)
print(anna.score)   // 0

Bei einer Klasse kann jede Funktion, die das Objekt bekommt, es verändern. Das ist manchmal genau das, was man will. Es kann aber auch zu Fehlern führen, die schwer zu finden sind: Irgendwo im Code ändert jemand ein Objekt, und an einer ganz anderen Stelle wundert man sich, warum sich die Daten geändert haben.

Struct oder Class?

Apples Empfehlung ist eindeutig:

Gute Gründe für eine Klasse:

• Geteilter Zustand: Mehrere Teile deiner App sollen auf dieselben Daten zugreifen und Änderungen sofort sehen. Ein typisches Beispiel ist ein „Datenspeicher“ für die ganze App.
• Identität: Es geht um ein ganz bestimmtes „Ding“, nicht nur um seine Werte, etwa eine Netzwerkverbindung oder eine geöffnete Datei.
• Ein Framework verlangt eine Klasse. In SwiftUI ist das bei @Observable so (Lektion 3.1), und auch SwiftData-Modelle sind Klassen (Lektion 3.14).

Für alles andere, also Bücher, Kontakte, Einstellungen, Rechenergebnisse, sind Structs die bessere Wahl. Sie sind einfacher zu verstehen, sicherer und meist auch schneller.

Was das mit SwiftUI zu tun hat

In SwiftUI begegnen dir beide Welten:

• Views sind Structs. SwiftUI erzeugt sie ständig neu und wirft sie weg. Das geht nur, weil Structs so leicht und günstig sind.
• Daten, die mehrere Views teilen, stecken oft in Klassen. Wenn eine Liste und eine Detailansicht dieselben Daten anzeigen und eine Änderung in der einen sofort in der anderen erscheinen soll, brauchst du einen geteilten Datenspeicher.

Genau diese Unterscheidung steckt hinter @State für einfache Werte (Lektion 2.9) und @Observable für Klassen (Lektion 3.1). Ohne das Wissen aus dieser Lektion wären die beiden kaum zu verstehen.

Vererbung: kurz erwähnt

Klassen können von anderen Klassen erben. Eine Unterklasse übernimmt dann alle Eigenschaften und Methoden und kann eigene hinzufügen:

class Animal {
    let name: String
    init(name: String) { self.name = name }
    func sound() -> String { "..." }
}

class Dog: Animal {
    override func sound() -> String { "Wuff!" }
}

let dog = Dog(name: "Bello")
print("\(dog.name) sagt \(dog.sound())")   // Bello sagt Wuff!

override zeigt an, dass eine Methode der Oberklasse ersetzt wird.

Vererbung war früher in der Apple-Welt sehr wichtig. In modernem Swift und SwiftUI verwendet man sie aber nur noch selten. Stattdessen nutzt man Protokolle (Lektion 1.15), die flexibler sind und auch mit Structs funktionieren. Deshalb belassen wir es bei diesem kurzen Blick.

Typische Fehler

Kein Initializer

class Player {
    var name: String
}

Klassen brauchen einen init, der allen Eigenschaften ohne Standardwert einen Wert gibt.

self. vergessen im Initializer

init(name: String) {
    name = name
}

Swift denkt, du willst dem Parameter name einen Wert zuweisen. Schreib self.name = name.

Unerwartete Änderung

Kein Fehler im Code, aber in der Logik: Du änderst ein Objekt an einer Stelle, und es ändert sich überall. Frag dich: Brauche ich hier wirklich eine Klasse, oder wäre eine Struct sicherer?

mutating in einer Klasse

class Counter {
    var count = 0
    mutating func increment() { count += 1 }
}

In Klassen gibt es kein mutating. Lass es einfach weg.

FAQ

Übungen

struct Point { var x = 0 }
var p1 = Point()
var p2 = p1
p2.x = 5
print(p1.x, p2.x)

class ShoppingCart {
    var items: [String] = []

    func add(_ item: String) {
        items.append(item)
    }
}

let cart = ShoppingCart()
let phoneView = cart
let tabletView = cart

phoneView.add("Kaffee")
tabletView.add("Milch")

print(phoneView.items)   // ["Kaffee", "Milch"]

Zusammenfassung

• Werttypen (struct, enum, Int, String, Array …) werden bei Zuweisung kopiert.
• Referenztypen (class) werden geteilt: Mehrere Verweise zeigen auf dasselbe Objekt.
• Klassen brauchen einen eigenen init, aber kein mutating.
• let bei einer Klasse heißt nur: Der Verweis bleibt gleich. Das Objekt darf sich ändern.
• Faustregel: standardmäßig struct, class nur bei geteiltem Zustand oder wenn ein Framework es verlangt.
• In SwiftUI: Views sind Structs, geteilte Daten stecken oft in Klassen (@Observable).

Spickzettel

class Player {
    var name: String
    init(name: String) { self.name = name }
    func rename(_ n: String) { name = n }   // kein mutating
}

let a = Player(name: "A")
let b = a          // derselbe Spieler!
a === b            // true, dasselbe Objekt