Menggunakan properti BOOL


111

Apple merekomendasikan untuk mendeklarasikan properti BOOL dengan cara ini:

@property (nonatomic, assign, getter=isWorking) BOOL working;

Karena saya menggunakan properti Objective-C 2.0 dan notasi titik, saya mengakses properti ini menggunakan self.working. Saya tahu bahwa saya juga dapat menggunakan [self isWorking]- tetapi saya tidak harus menggunakannya.

Jadi, karena saya menggunakan notasi titik di mana-mana, mengapa saya harus mendefinisikan properti tambahan? Apakah tidak apa-apa jika hanya menulis

@property (nonatomic, assign) BOOL working;

Atau apakah saya memiliki keuntungan menulis getter=isWorkingdalam kasus saya (penggunaan notasi titik)?

Terima kasih!


4
Bukankah ini rekomendasi berbasis semantik? jadi myCar.isWorking akan secara semantik lebih akurat daripada myCar.working
justcompile

Jawaban:


206

Apple hanya merekomendasikan mendeklarasikan isXgetter untuk tujuan gaya. Tidak masalah apakah Anda menyesuaikan nama pengambil atau tidak, selama Anda menggunakan notasi titik atau pesan dengan nama yang benar. Jika Anda akan menggunakan notasi titik tidak ada bedanya, Anda tetap mengaksesnya dengan nama properti:

@property (nonatomic, assign) BOOL working;

[self setWorking:YES];         // Or self.working = YES;
BOOL working = [self working]; // Or = self.working;

Atau

@property (nonatomic, assign, getter=isWorking) BOOL working;

[self setWorking:YES];           // Or self.working = YES;, same as above
BOOL working = [self isWorking]; // Or = self.working;, also same as above

4
Tentunya ini lebih berkaitan dengan kepatuhan pengkodean nilai kunci daripada hanya tujuan gaya?
Jasarien

5
Agak aneh bahwa Apple merekomendasikan untuk mendeklarasikan isXgetter tersebut tetapi Xcode tidak dapat mencantumkannya di popup pelengkapan otomatis. (Dalam contoh saya) workingterdaftar di sana, tetapi isWorkingtidak. Jadi saya tidak melihat manfaat apa pun dalam mendeklarasikan pengambil BOOL. Saya harus berbuat lebih banyak untuk dapat menggunakannya (nyatakan pengambil) tetapi saya mendapatkan lebih sedikit (tidak ada penyelesaian otomatis).
Patrick

4

Apple merekomendasikan untuk tujuan gaya. Jika Anda menulis kode ini:

@property (nonatomic,assign) BOOL working;

Maka Anda tidak dapat menggunakan [object isWorking].
Ini akan menunjukkan kesalahan. Tetapi jika Anda menggunakan kode di bawah ini berarti

@property (assign,getter=isWorking) BOOL working;

Jadi Anda bisa menggunakan [object isWorking].


-26

Tidak ada manfaatnya menggunakan properti dengan tipe primitif. @propertydigunakan dengan tumpukan dialokasikan NSObjectsseperti NSString*, NSNumber*, UIButton*, dan sebagainya, karena memori dikelola accesor diciptakan secara gratis. Saat Anda membuat BOOL, nilai selalu dialokasikan di tumpukan dan tidak memerlukan pengakses khusus apa pun untuk mencegah kebocoran memori. isWorkinghanyalah cara populer untuk mengekspresikan keadaan nilai boolean.

Dalam bahasa OO lain Anda akan membuat variabel private bool working;dan dua pengakses: SetWorkinguntuk penyetel dan pengakses IsWorking.


1
Anda tidak menjawab pertanyaannya, yaitu apa tujuan dari memberi nama getter secara eksplisit selain properti (dia tidak menanyakan apakah properti adalah ide yang bagus). Selain itu, properti mengizinkan KVO dan KVC, jadi poin yang Anda buat menyesatkan.
Martin Gjaldbaek

Anda benar bahwa saya mengabaikan penggunaan KVO dan KVC dengan properti primitif. Saya pikir semua orang di utas menjawab pertanyaannya tentang isWorking - ini adalah konvensi penamaan.
Thomson Comer

25
Ini sepenuhnya tidak benar; @propertysangat dimaksudkan untuk digunakan dengan tipe primitif dan, demi konsistensi saja, memiliki keuntungan yang signifikan. Lebih lanjut, beberapa tipe primitif (tipe 64 bit pada beberapa CPU 32 bit dan tipe 128 bit pada banyak CPU 32 dan 64 bit) adalah non-atomic pada penugasan; @propertyatomicity dapat menguntungkan dalam kasus tersebut juga.
bbum

1
Menarik - tapi bagaimana sih saya bisa tahu itu? :) Apakah ini implikasi dari atribut atomicdan nonatomic?
Thomson Comer
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.