Antwort.

Historisch wurden in Objective-C Eigenschaften durch Zugriffs-Methoden (Getter und Setter) implementiert. In Swift wurde eine spezielle Syntax für computed properties eingeführt, die es ermöglicht, Eigenschaften zu erstellen, die ihren Wert "on the fly" berechnen. Dies erweitert die Möglichkeiten der Kapselung und Ausdruckskraft von Typ-Code.

Problem: Es ist nicht immer praktisch, das Ergebnis als stored property zu speichern, insbesondere wenn der Wert von anderen Eigenschaften abhängt oder sich häufig ändert. Die Verwendung von Berechnungsmethoden führt zu einer weniger lesbaren Typ-Schnittstelle, da sie deren Natur verbirgt.

Lösung: Eine computed property wird mit get und, wenn nötig, set definiert. Bei jedem Zugriff auf eine solche Eigenschaft wird eine Berechnung durchgeführt und kein Lesen aus dem Speicher. Dies ermöglicht beispielsweise, abgeleitete Eigenschaften zu erstellen, die automatisch mit dem restlichen Zustand des Objekts synchronisiert sind.

Beispielcode:

struct Rectangle {
    var width: Double
    var height: Double
    var area: Double {
        get {
            return width * height
        }
        set {
            // Automatisches Update von width basierend auf dem neuen Wert von area (Beispiel)
            width = sqrt(newValue / height)
        }
    }
}

var rect = Rectangle(width: 5, height: 2)
print(rect.area) // 10
rect.area = 36
print(rect.width) // 3.0

Schlüsselmerkmale:

Die computed property benötigt keinen zusätzlichen Speicher, ihr Ergebnis wird nicht automatisch gespeichert.
Kann nur get oder get und set haben.
Bequemer Weg, abgeleitete oder synchronisierte Eigenschaften zu erstellen.

Fangfragen.

Kann man willSet/didSet mit computed properties verwenden?

Nein, willSet und didSet sind nur für stored properties anwendbar. Für computed properties funktionieren diese Beobachter nicht, da es keine automatische Speicherung des Wertes gibt.

Kann eine computed property einen optionalen oder implizit entpackten Typ haben?

Ja, eine computed property kann optional oder implizit entpackt sein. Es macht jedoch keinen Sinn, solche Eigenschaften weak zu machen, da sie keinen Verweis enthalten – nur Berechnung.

In welchen Fällen ist es besser, private set in einer computed property zu verwenden?

Der Zugriffsmodifikator private(set) kann nicht auf eine computed property mit get und set angewendet werden, nur auf stored properties. Für eine computed property kann set ganz privat mit private set sein, aber das wird implizit durch die Verfügbarkeit des set-Blocks realisiert.

public var area: Double {
    private set { ... }
    get { ... }
}

Typische Fehler und Anti-Pattern

Durchführung von schweren, langwierigen Berechnungen im get-Block, was zu schlechter Leistung führt.
Mutation des Zustands innerhalb des Getters, was das Konzept der side-effect-free accessor stört.
Falsche Verwendung von set, wenn die Änderung einer Eigenschaft andere beeinträchtigen sollte.

Beispiel aus dem Leben

Negativer Fall

Der Getter der computed property lädt bei jedem Zugriff große Daten aus dem Netzwerk, was zu Friesen und Netzwerküberlastung führt.

Vorteile:

Einfache Verwendung für kleine Daten.

Nachteile:

Zerbrechlichkeit und unvorhersehbares Verhalten bei echten Daten.
Deutlicher negativer Einfluss auf die Leistung und den Energieverbrauch.

Positiver Fall

Die computed property berechnet den Endwert basierend auf anderen stored properties mit minimalen Kosten, das Caching von schweren Logiken wurde in einen separaten Mechanismus ausgelagert.