Использование свойства BOOL


111

Apple рекомендует объявить свойство BOOL следующим образом:

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

Поскольку я использую свойства Objective-C 2.0 и точечную нотацию, я получаю доступ к этому свойству, используя self.working. Я знаю, что тоже могу использовать [self isWorking]- но мне не обязательно.

Итак, поскольку я везде использую точечную нотацию, зачем мне определять дополнительное свойство? Было бы хорошо просто написать

@property (nonatomic, assign) BOOL working;

Или у меня есть какие-то преимущества написания getter=isWorkingв моем случае (использование точечной записи)?

Спасибо!


4
Разве это не семантическая рекомендация? поэтому myCar.isWorking будет семантически более точным, чем myCar.working
скомпилируйте

Ответы:


206

Apple просто рекомендует объявить isXгеттер в стилистических целях. Неважно, настраиваете ли вы имя получателя или нет, если вы используете точечную нотацию или нотацию сообщения с правильным именем. Если вы собираетесь использовать точечную нотацию, это не имеет значения, вы все равно получаете доступ к нему по имени свойства:

@property (nonatomic, assign) BOOL working;

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

Или

@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
Конечно, это больше связано с тем, чтобы кодирование ключевых значений соответствовало требованиям, чем просто стилистические цели?
Jasarien

5
Немного странно, что Apple рекомендует объявлять эти isXгеттеры, но Xcode не может перечислить их во всплывающем окне автозаполнения. (В моем примере) workingтам указано, но isWorkingнет. Поэтому я не вижу никаких преимуществ в объявлении получателей BOOL. Мне нужно сделать больше, чтобы использовать их (объявить получатель), но я получаю меньше (без автозаполнения).
Патрик

4

Apple рекомендует в стилистических целях. Если вы напишете этот код:

@property (nonatomic,assign) BOOL working;

Тогда вы не сможете использовать [object isWorking].
Это покажет ошибку. Но если вы используете код ниже, значит

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

Итак, вы можете использовать [object isWorking].


-26

Нет никакой пользы от использования свойств с примитивными типами. @propertyиспользуются с кучей выделенной , NSObjectsкак NSString*, NSNumber*, UIButton*, и т.д., потому что память удался аксессоры созданы бесплатно. Когда вы создаете BOOL, значение всегда выделяется в стеке и не требует специальных средств доступа для предотвращения утечки памяти. isWorking- это просто популярный способ выражения состояния логического значения.

В другом объектно-ориентированном языке вы должны создать переменную private bool working;и два средства доступа: SetWorkingдля установщика и IsWorkingдля средства доступа.


1
Вы не отвечаете на его вопрос, а именно, какова цель явного именования получателя чего-то еще, кроме свойства (он не спрашивает, являются ли свойства хорошей идеей). Кроме того, свойства позволяют использовать KVO и KVC, поэтому ваша мысль вводит в заблуждение.
Мартин Гьялдбек 01

Вы правы, что я упустил из виду использование KVO и KVC с примитивными свойствами. Я думаю, что каждый в теме отвечает на свой вопрос относительно isWorking - это соглашение об именах.
Томсон Комер

25
Это совершенно неверно; @propertyв значительной степени предназначен для использования с примитивными типами и, только ради согласованности, имеет значительные преимущества. Кроме того, некоторые примитивные типы (64-разрядные типы на некоторых 32-разрядных процессорах и 128-разрядные типы на многих 32- и 64-разрядных процессорах) не являются атомарными при назначении; @propertyатомарность тоже может быть выгодна в этих случаях.
bbum 01

1
Интересно, но откуда мне это знать? :) Является ли это неявно из atomicи nonatomicатрибутов?
Томсон Комер
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.