Sử dụng thuộc tính BOOL


110

Apple khuyến nghị khai báo thuộc tính BOOL theo cách này:

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

Vì tôi đang sử dụng thuộc tính Objective-C 2.0 và ký hiệu dấu chấm, tôi truy cập thuộc tính này bằng cách sử dụng self.working. Tôi biết rằng tôi cũng có thể sử dụng [self isWorking]- nhưng tôi không cần phải làm thế.

Vì vậy, vì tôi đang sử dụng ký hiệu dấu chấm ở khắp mọi nơi, tại sao tôi phải xác định một thuộc tính bổ sung? Có thể viết đơn giản được không

@property (nonatomic, assign) BOOL working;

Hoặc tôi có bất kỳ lợi ích nào khi viết getter=isWorkingtrong trường hợp của tôi (sử dụng ký hiệu dấu chấm)?

Cảm ơn!


4
Đây không phải là một khuyến nghị dựa trên ngữ nghĩa? vì vậy myCar.isWorking sẽ chính xác hơn về mặt ngữ nghĩa so với myCar.working
justcompile

Câu trả lời:


205

Apple chỉ đơn giản khuyến nghị khai báo một isXgetter cho các mục đích phong cách. Không quan trọng bạn có tùy chỉnh tên getter hay không, miễn là bạn sử dụng ký hiệu dấu chấm hoặc ký hiệu thông báo với tên chính xác. Nếu bạn định sử dụng ký hiệu dấu chấm, điều đó không có gì khác biệt, bạn vẫn truy cập nó bằng tên thuộc tính:

@property (nonatomic, assign) BOOL working;

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

Hoặc là

@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
Chắc chắn nó liên quan nhiều hơn đến việc tuân thủ mã hóa giá trị quan trọng hơn là chỉ các mục đích phong cách?
Jasarien

5
Hơi lạ khi Apple khuyên bạn nên khai báo những isXgetters đó nhưng Xcode không thể liệt kê chúng trong cửa sổ bật lên tự động hoàn thành. (Trong ví dụ của tôi) workingđược liệt kê ở đó, nhưng isWorkingkhông phải. Vì vậy, tôi không thấy bất kỳ lợi ích nào trong việc khai báo BOOL getters. Tôi phải làm nhiều hơn để có thể sử dụng chúng (khai báo getter) nhưng tôi nhận được ít hơn (không có tự động hoàn thành).
Patrick

4

Apple đề xuất cho các mục đích phong cách. Nếu bạn viết mã này:

@property (nonatomic,assign) BOOL working;

Sau đó, bạn không thể sử dụng [object isWorking].
Nó sẽ hiển thị một lỗi. Nhưng nếu bạn sử dụng mã dưới đây có nghĩa là

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

Vì vậy, bạn có thể sử dụng [object isWorking].


-26

Không có lợi ích gì khi sử dụng các thuộc tính với các kiểu nguyên thủy. @propertyđược sử dụng với đống phân bổ NSObjectsnhư NSString*, NSNumber*, UIButton*, và vv, vì accessors bộ nhớ được quản lý được tạo ra miễn phí. Khi bạn tạo a BOOL, giá trị luôn được phân bổ trên ngăn xếp và không yêu cầu bất kỳ trình truy cập đặc biệt nào để ngăn rò rỉ bộ nhớ. isWorkingchỉ đơn giản là cách phổ biến để thể hiện trạng thái của một giá trị boolean.

Trong một ngôn ngữ OO khác, bạn sẽ tạo một biến private bool working;và hai bộ truy cập: SetWorkingcho bộ định vị và IsWorkingbộ truy cập.


1
Bạn không trả lời câu hỏi của anh ta, cụ thể là mục đích của việc đặt tên rõ ràng cho getter thứ gì đó khác với thuộc tính (anh ta không hỏi liệu thuộc tính có phải là một ý tưởng hay không). Ngoài ra, các thuộc tính cho phép KVO và KVC, vì vậy điểm bạn đưa ra là sai lệch.
Martin Gjaldbaek

Bạn nói đúng rằng tôi đã bỏ qua việc sử dụng KVO và KVC với các thuộc tính nguyên thủy. Tôi nghĩ mọi người trong chuỗi đang giải quyết câu hỏi của anh ấy về isWorking - đó là một quy ước đặt tên.
Thomson Comer

25
Điều này hoàn toàn không chính xác; @propertyđược dự định rất nhiều để được sử dụng với các loại nguyên thủy và, chỉ vì mục đích nhất quán, có những lợi thế đáng kể. Hơn nữa, một số kiểu nguyên thủy (kiểu 64 bit trên một số CPU 32 bit và kiểu 128 bit trên nhiều CPU 32 và 64 bit) là phi nguyên tử khi gán; @propertyTính nguyên tử của cũng có thể có lợi trong những trường hợp đó.
bbum

1
Thật thú vị - nhưng làm thế quái nào mà tôi phải biết điều đó? :) Đây có phải là sự không đồng nhất của các thuộc tính atomicnonatomic?
Thomson Comer
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.