Соглашения об именах для свойств BOOL Obj-C 2?

Question

У меня есть свойство только для чтения BOOL. Каков здесь доминирующий шаблон именования?

Справочная информация: для простых объявлений старых методов принят шаблон

- (BOOL)isEditable;
- (void)setEditable:(BOOL)flag;

В мире @property это обычно выражается как

@property(getter=isEditable) BOOL editable;

Однако есть примеры обратного. Например, в CalStore / CalCalendar.h

@property(readonly) BOOL isEditable;

(CalCalendar здесь неверен или это также приемлемый шаблон именования свойств BOOL только для чтения?)

У меня есть контроллер, который управляет видом, размер которого может изменяться или не изменяться. Свойство только для чтения.

@property(readonly) BOOL viewIsResizable;
@property(readonly) BOOL isViewResizable;
@property(readonly, getter=isViewResizable) BOOL viewResizable;

Какой рисунок наиболее натуральный или какао-подобный?

Answer 1

цитата из АЦП

Если атрибут выражен как прилагательное, формат:

- (void)setAdjective:(BOOL)flag;
- (BOOL)isAdjective;

Например:

- (void)setEditable:(BOOL)flag;
- (BOOL)isEditable; 

Если атрибут выражен в виде глагола, формат:

- (void)setVerbObject:(BOOL)flag; 
- (BOOL)verbObject;

Например:

- (void)setShowsAlpha:(BOOL)flag;
- (BOOL)showsAlpha; 

Глагол должен быть в простом настоящем времени.

| K <</p>

Answer 2

Я не думаю, что это действительно имеет значение, так как KVO будет смотреть на is<Key> и <Key>.

Глядя на классы iPhone, наиболее распространенный шаблон, который я видел:

@ свойство (неатомное, getter = isHidden) BOOL скрыто;

Это позволит вам получить доступ к свойству следующими способами:

obj.hidden = YES; // (1)
BOOL hidden = obj.hidden; // (2)
BOOL hidden = [obj isHidden]; // (3)

Но не:

BOOL hidden = obj.isHidden; // (4)

CalStore не следует этому соглашению. Вы должны будете использовать строку 4 вместо строки 2.

Answer 3

Вы хотите использовать тот, который работает с KVO, KVC и привязками и т. Д.

Я помню, что читал это в Документах, которые KVO et al. будет искать is<i><key></i>, set<i><key></i>, а также get<i><key></i> и многие другие, такие как countOf<<i>key></i>

Контрольный список KVC соответствия объясняет это гораздо лучше, чем я когда-либо мог.

Answer 4

Пример CalStore, кажется, нарушает соглашение. Я придерживаюсь того, что в имени свойства, в отличие от имени метода, нет «is»

Answer 5

Соглашение определенно должно делать is... для получателей BOOL. Причина, по которой вы видите подобное свойство в CalStore, наиболее вероятна, потому что он доступен только для чтения и записан таким образом для базовой читабельности файла заголовка, поскольку:

@property(readonly) isEditable;

обычно легче читать, чем:

@property(readonly, getter=isEditable) editable;

Для свойства первого типа в вашей реализации вы можете сделать одно из:

@synthesize isEditable = editable;

или просто определите метод доступа:

- (BOOL)isEditable(void) { return editable; }

Это оставляет интерфейсный файл (заголовок) более легким для чтения потенциальным пользователем.