Cevap.

Tarihsel olarak Objective-C'de özellikler erişim yöntemleri (getter'lar ve setter'lar) aracılığıyla uygulanmıştır. Swift, değeri "anlık" olarak hesaplayan özellikler oluşturmayı kolaylaştıran özel bir sözdizimsel yapı getirmiştir. Bu, tiplerin kapsülleme ve ifade edilebilirlik yeteneklerini genişletir.

Sorun: Sonuçları depolanan özellik olarak saklamak her zaman uygun değildir, özellikle değer diğer özelliklere bağlıysa veya sürekli değişiyorsa. Hesaplama yöntemleri kullanmak, tipin doğasını gizleyerek daha az okunabilir bir arayüz oluşturur.

Çözüm: Hesaplanan özellik, get ve gerekirse set kullanılarak tanımlanır. Bu tür bir özelliğe her erişimde hesaplama gerçekleştirilir, bellek okumak yerine. Bu, örneğin, diğer nesne durumuyla otomatik olarak senkronize olan türetilmiş özellikler (derived properties) oluşturmayı mümkün kılar.

Kod örneği:

struct Rectangle {
    var width: Double
    var height: Double
    var area: Double {
        get {
            return width * height
        }
        set {
            // area alanı için yeni değere göre width'in otomatik güncellenmesi (örnek)
            width = sqrt(newValue / height)
        }
    }
}

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

Ana özellikler:

Hesaplanan özellik ek bellek harcamaz, sonucu otomatik olarak saklanmaz.
Sadece get veya get ve set içerebilir.
Türetilmiş veya senkronize özellikler oluşturmanın kullanışlı bir yoludur.

Kandırma Soruları.

Hesaplanan özellik ile willSet/didSet kullanılabilir mi?

Hayır, willSet ve didSet yalnızca depolanan özelliklerle uygulanabilir. Hesaplanan özellikler için bu gözlemciler çalışmaz, çünkü değer otomatik olarak saklanmaz.

Hesaplanan özellik zayıf (weak) veya örtük olarak genişletilmiş (implicitly unwrapped) bir tipe sahip olabilir mi?

Evet, hesaplanan özellik opsiyonel veya örtük olarak genişletilmiş olabilir. Ancak, bu tür özellikleri zayıf yapmak anlamlı değildir, çünkü referans içermezler — yalnızca hesaplama içerirler.

Hesaplanan özellikte private set kullanmak hangi durumlarda daha iyidir?

Erişim belirleyici private(set), sadece depolanan özelliklere uygulanabilir, hesaplanan özelliklere uygulanamaz. Hesaplanan özellik için set tamamen özel olabilir, ancak bu set bloğunun erişilebilirliği yoluyla gizli olarak gerçekleştirilir.

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

Yaygın Hatalar ve Anti-Desenler

Get bloğunda ağır, uzun hesaplamalar yapmak, performans düşüklüğüne yol açar.
Getter içinde durumun değiştirilmesi, yan etkisiz erişimcilerin (side-effect-free accessor'lar) konseptini ihlal eder.
Set'in yanlış kullanımı, bir özelliğin değişiklikleri birden fazla diğerini etkilemesi gerektiğinde ortaya çıkar.

Hayattan Bir Örnek

Olumsuz Durum

Hesaplanan özellik, her erişimde ağdan büyük verileri yükleyerek, donmalara ve ağın aşırı yüklenmesine neden olur.

Artıları:

Küçük veriler için kullanım kolaylığı.

Eksileri:

Kırılganlık ve gerçek verilerde öngörülemeyen davranış.
Performans ve enerji tüketimi üzerinde önemli olumsuz etki.

Olumlu Durum

Hesaplanan özellik, diğer depolanan özelliklere dayalı olarak nihai değeri minimum maliyetle hesaplar, ağır mantığın önbelleklenmesi ayrı bir mekanizmaya taşınmıştır.