Соглашения об именах для свойств BOOL Obj-C 2?
У меня есть свойство 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;
Какой шаблон наиболее естественный или Cocoa -like?
Ответы
Ответ 1
цитируется ADC
Если атрибут выражается как прилагательное, формат:
- (void)setAdjective:(BOOL)flag;
- (BOOL)isAdjective;
Например:
- (void)setEditable:(BOOL)flag;
- (BOOL)isEditable;
Если атрибут выражается в виде глагола, формат:
- (void)setVerbObject:(BOOL)flag;
- (BOOL)verbObject;
Например:
- (void)setShowsAlpha:(BOOL)flag;
- (BOOL)showsAlpha;
Глагол должен находиться в простом настоящем времени.
| К <
Ответ 2
Я не думаю, что это действительно имеет значение, так как KVO будет смотреть как на is<Key>
, так и на <Key>
.
Глядя на классы iPhone, наиболее распространенный шаблон, который я видел, это:
@property (nonatomic, getter = isHidden) BOOL hidden;
Это позволит вам получить доступ к свойству следующими способами:
obj.hidden = YES; // (1)
BOOL hidden = obj.hidden; // (2)
BOOL hidden = [obj isHidden]; // (3)
Но не:
BOOL hidden = obj.isHidden; // (4)
CalStore не следует этому соглашению. Вам нужно будет использовать строку 4 вместо строки 2.
Ответ 3
Вы хотите использовать тот, который работает с KVO, KVC и привязками и т.д.
Я помню, как читал это в Документах, которые KVO et al. будет искать is <key>
, set <key>
а также get <key>
и многие другие, такие как countOf< key>
Контрольный список соответствия KVC объясняет это гораздо лучше, чем я когда-либо мог.
Ответ 4
Пример CalStore, похоже, нарушает соглашение. Я буду придерживаться того, где имя свойства, в отличие от имени метода, не имеет в нем "is".
Ответ 5
Соглашение, безусловно, должно делать is...
для BOOL getters. Причина, по которой вы видите свойство, установленное в CalStore, скорее всего, потому что оно доступно только для чтения и написано таким образом для базовой читаемости файла заголовка, поскольку:
@property(readonly) isEditable;
как правило, легче читать, чем:
@property(readonly, getter=isEditable) editable;
Для первого типа свойства в вашей реализации вы можете выполнить любое из следующих действий:
@synthesize isEditable = editable;
или просто определите accessor:
- (BOOL)isEditable(void) { return editable; }
Это оставляет файл интерфейса (заголовок) более легко читаемым потенциальным пользователем.