Antwoord.

Historisch gezien were eigenschappen in Objective-C geïmplementeerd via toegangsmethoden (getters en setters). In Swift is een speciale syntactische constructie voor computed properties geïntroduceerd, waarmee je gemakkelijk eigenschappen kunt maken die hun waarde "on-the-fly" berekenen. Dit breidt de mogelijkheden van encapsulatie en expressie van typecode uit.

Probleem: Het is niet altijd handig om het resultaat op te slaan als een stored property, vooral als de waarde afhankelijk is van andere eigenschappen of constant verandert. Het gebruik van rekenmethoden creëert een minder leesbaar type-interface, waardoor de aard ervan verborgen wordt.

Oplossing: Een computed property wordt gedefinieerd met behulp van get en, indien nodig, set. Bij elke toegang tot zo'n eigenschap wordt een berekening uitgevoerd in plaats van lezen uit het geheugen. Dit stelt je bijvoorbeeld in staat om derived properties te bouwen die automatisch gesynchroniseerd zijn met de rest van de toestand van het object.

Voorbeeldcode:

struct Rectangle {
    var width: Double
    var height: Double
    var area: Double {
        get {
            return width * height
        }
        set {
            // Automatische update van width naar de nieuwe waarde van het gebied (voorbeeld)
            width = sqrt(newValue / height)
        }
    }
}

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

Belangrijke kenmerken:

Een computed property neemt geen extra geheugen in, de resultaten worden niet automatisch opgeslagen.
Ze kunnen alleen get of get en set hebben.
Een handige manier om derived of gesynchroniseerde eigenschappen te creëren.

Vragen met een twist.

Kun je willSet/didSet gebruiken met computed property?

Nee, willSet en didSet zijn alleen toepasbaar op stored properties. Voor computed properties werken deze observatoren niet, omdat er geen automatische opslag van waarden is.

Kan een computed property een zwakke of impliciet uitgepakte type hebben?

Ja, een computed property kan optioneel of impliciet uitgepakt zijn. Het heeft echter geen zin om zulke eigenschappen weak te maken, omdat ze geen referentie bevatten — alleen een berekening.

In welke gevallen is het beter om private set te gebruiken in een computed property?

De toegangsmodule private(set) kan niet worden toegepast op een computed eigenschap met get en set, alleen op een stored property. Voor een computed property kan set volledig privé zijn met behulp van private set, maar dit wordt impliciet gerealiseerd via de beschikbaarheid van de set-blok.

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

Typische fouten en antipatterns

Uitvoeren van zware, langdurige berekeningen in de get-blok, wat leidt tot zwakke prestaties.
Mutatie van de toestand binnen de getter, wat het concept van side-effect-free accessors schaadt.
Onjuist gebruik van set, waarbij een wijziging van één eigenschap invloed moet hebben op verschillende andere.

Voorbeeld uit het leven

Negatieve case

De getter van de computed property laadt steeds grote gegevens uit het netwerk, elke keer bij toegang, wat leidt tot freezes en overbelasting van het netwerk.

Voordelen:

Eenvoudig te gebruiken voor kleine gegevens.

Nadelen:

Fragiliteit en onvoorspelbaar gedrag bij echte data.
Een aanzienlijke negatieve impact op prestaties en energieverbruik.

Positieve case

De computed property berekent de uiteindelijke waarde op basis van andere stored properties met minimale kosten, waarbij de caching van zware logica naar een apart mechanisme is verplaatst.