ARC kapsamındaki mülkler: Her zaman mı yoksa sadece herkese açık mı?

İki yıldan daha kısa bir süre önce Robert McNally tarafından "Kod Komutları: Objective-C Kodlaması için En İyi Uygulamalar" adlı alçakgönüllü bir makaleyi okuduktan sonra , Objective-C sınıflarımın hemen hemen her veri üyesi için özellik kullanma uygulamasını kabul ettim ( Mayıs 2012 itibariyle 3. emir). McNally bunu yapmak için şu nedenleri listeler (benim vurgu):

1. Özellikler erişim kısıtlamalarını zorunlu kılar (salt okunur gibi)
2. Özellikler bellek yönetimi politikasını zorunlu kılar (güçlü, zayıf)
3. Özellikler, özel ayarlayıcıları ve alıcıları şeffaf bir şekilde uygulama fırsatı sunar.
4. İş parçacığı güvenliği stratejisini uygulamak için özel ayarlayıcılar veya alıcılar içeren özellikler kullanılabilir.
5. Örnek değişkenlerine erişmenin tek bir yoluna sahip olmak kod okunabilirliğini artırır.

Mülklerimin çoğunu özel kategorilere koydum, bu nedenle 1 ve 4 sayısı genellikle çalıştığım konular değil. 3 ve 5 numaralı argümanlar daha yumuşaktır ve doğru araçlar ve diğer tutarlılıklarla sorun yaratmayabilirler. Son olarak, bu argümanlardan en etkili olanı 2 numaralı bellek yönetimi idi. Bunu o zamandan beri yapıyorum.

@property (nonatomic, strong) id object; // Properties became my friends.

Son birkaç projem için ARC'yi kullanmaya başladım, bu da hemen hemen her şey için özellik oluşturmanın hala iyi bir fikir mi, yoksa biraz gereksiz mi olduğundan şüphe duymamı sağladı. ARC, Objective-C nesnelerini benim için yöneten bellekle ilgileniyor, bu da çoğu strongüye için sadece ivar'ları beyan ederseniz iyi çalışıyor. AR-öncesi ve sonrasında yine de manuel olarak yönetmeniz gereken C-tipleri ve weaközellikler çoğunlukla herkese açıktır.

Tabii ki hala sınıfın dışından erişilmesi gereken her şey için özellikleri kullanıyorum, ancak çoğu veri üyesi uygulama başlığı altında ivar olarak listelenirken, bunlar çoğunlukla sadece bir avuç özelliktir.

@implementation GTWeekViewController
{
    UILongPressGestureRecognizer *_pressRecognizer;
    GTPagingGestureRecognizer *_pagingRecognizer;
    UITapGestureRecognizer *_tapRecognizer;
}

Bir deney olarak bunu biraz daha titiz bir şekilde yapıyorum ve her şey için özelliklerden uzaklaşmanın bazı olumlu olumlu yan etkileri var.

1. Veri üye kodu gereksinimleri ( @property/ @synthesize) sadece ivar bildirimine kadar küçüldü.
2. self.somethingReferanslarımın çoğu sadece temizlendi _something.
3. Hangi veri üyelerinin özel (ivars) ve hangilerinin halka açık (mülkler) olduğu kolayca ayırt edilebilir.
4. Son olarak, Apple'ın amaçladığı amaçların bu olduğu gibi 'hissediyor', ancak bu öznel spekülasyon.

Soru üzerine : Yavaşça karanlık tarafa doğru kayarım, uygulama ivarları lehine daha az özellik kullanarak. Bana neden her şey için özellik kullanmaya bağlı kalmam gerektiğine dair biraz akıl sağlayabilir misin, ya da neden sadece gerektiğinde daha fazla ivar ve daha az özellik kullanmam gerektiğine dair mevcut düşünce trenimi onaylayabilir misin? Her iki taraf için en ikna edici cevap notumu alacak.

DÜZENLEME: McNally Twitter'da ağırlıyor: "Bence mülklere bağlı kalmamın temel nedeni: her şeyi yapmanın bir yolu, her şeyi (KVC / KVO dahil) yapıyor."

Bana neden her şey için özellik kullanmaya bağlı kalmam gerektiğine dair biraz akıl sağlayabilir misin, ya da neden sadece gerektiğinde daha fazla ivar ve daha az özellik kullanmam gerektiğine dair mevcut düşünce trenimi onaylayabilir misin?

Şu anda, çoğunlukla bir stil meselesi olduğunu söylemek adil olur. Söylediğiniz gibi, ARC ile özelliklerin bellek yönetimi avantajı daha az önemlidir. Öte yandan, doğrudan ivar erişimine geri dönmenin "faydaları" da pek ilgi çekici değil:

1. Bir @ mülkiyet beyanı, bir ivar beyanına oldukça benzer. @Synthesize yönergesinden kaçınmak büyük bir kazanç gibi görünmüyor - çok fazla koddan bahsetmiyoruz.

2. foo.somethingSözdizimi çok daha iyi daha tartışmalı olduğu _something. Mülk erişim sözdizimi, bir yapının üyelerine erişmek için C'nin nokta sözdizimine benzeyecek şekilde çalışacak şekilde tasarlanmıştır. Hangi nesneye (bu selfya da başka bir şeye) eriştiğiniz konusunda açık olmak yararlıdır. (Bazı insanlar - ben değil! - self->somethingivar erişimini bu nedenle savunuyorlar .) İvarlar için önde gelen alt çizgi kuralı gayet iyi, ancak tüm Objective-C kodu tarafından tutarlı bir şekilde kullanılmıyor.

3. Özellikler, aynı sınıftaki diğer nesnelerde ("özel" erişim altında izin verilir) depolanan verilere erişmek ve alt sınıfların (C ++ 'korumalı "gibi) erişimi için daha iyi bir seçim gibi görünüyor. Dolayısıyla 'properties == public' fikri biraz bulanık.

4. Benim düşüncem, özelliklerin bellek yönetimini basitleştirmek ve diğer bazı faydalar sağlamak için tasarlandığını düşünüyorum. Dediğiniz gibi, bellek yönetimi avantajı azaldıkça, özellikler daha az çekici görünüyor.

Seçtiğiniz yol - dahili veriler için ivar erişimine yönelmek - çok makul bir seçim gibi görünüyor ve rotanızı değiştirmek için açık bir neden yok. Ancak özelliklere sadık kalmak da oldukça makul - dezavantajlar önemli değil ve KVO uyumluluğu ve daha tutarlı bir üye erişim stili gibi bazı güzel avantajlar var.

Mülkiyet, Objective-C'nin evriminde son adım değildi ve ARC'nin de olmasını beklemiyorum. Belirli bir bilgim yok, ancak özellikleri daha çekici veya daha az yapan bir noktada ek özelliklerin eklenebileceği iyi bir tahmin gibi görünüyor. Beklemek ve ne olacağını görmek zorundayız.

Ben de bu soruyu düşünmeye başladım. Benim düşünceme göre, sadece erişimciler için özellikler kullanmak kodu çok daha okunaklı hale getirir. Hangi değişkenlerin herkese açık olarak erişilmesi gerektiğini hemen görebilirsiniz. Ve kişisel olarak, her zaman bir değişkenin önüne @property (...) yazmak zaman alıcıdır.