В чем вред переопределения свойств в Objective-C? - PullRequest
18 голосов
/ 13 апреля 2011

Есть несколько ситуаций, когда вы можете переопределить свойство суперкласса.

  1. Вы объявляете свойство с тем же именем и тем же атрибутом его суперкласса '. (Поскольку при измененииАтрибут вы можете получить предупреждение компилятора). И вы можете синтезировать с помощью созданного вами ивара.Какая польза от этого?Или какой вред это может принести?

  2. Если суперкласс объявляет свойство в расширении класса (категории без имени), то оно может отсутствовать в заголовочном файле.Если вы не знаете это свойство из заголовочного файла, вы можете объявить то же свойство name с тем атрибутом или классом, который вам нужен.Но метод установки / получения переопределяет методы для этого "секретного свойства".Я думаю, что это может только навредить.Но так как вы не знаете из файла заголовка, как вы можете избежать этого?

  3. Вы можете объявить свойство в файле заголовка как «только для чтения», а в расширении класса переопределить его как"читай пиши".Я думаю, что в этой ситуации это может принести пользу.

Правильно ли мое понимание этих ситуаций?И я не знаю, что хорошего могут сделать первая и вторая ситуации.Но если я хочу избежать первой ситуации, я могу проверить, есть ли у подкласса свойство, прежде чем объявить его.Но если свойство отсутствует в общедоступном заголовочном файле, как во второй ситуации, я просто не знаю, что делать.

Ответы [ 2 ]

5 голосов
/ 13 апреля 2011

Для каждой из упомянутых вами ситуаций есть подходящее место с разной частотой использования в условиях дикой природы.Вы просто должны быть осторожны, чтобы не наступить на себя.Я проиллюстрирую на примере, с которым я лично сталкивался.

Подклассы для намеренного переопределения свойства
В этой ситуации, как упоминал Джо, вам лучше точно знать, что выделать и не иметь других вариантов, прежде чем переопределить свойство.Я лично обнаружил, что обычно достаточно переопределить один установщик или получатель для уже существующего свойства, чтобы выполнить настройку, а не повторно объявлять и синтезировать свойство.Например, рассмотрим специализированный подкласс UIView, который имеет смысл только иметь фон UIClearColor.Для этого вы можете переопределить -setBackgroundColor:, чтобы просто напечатать предупреждающее сообщение, а затем не вызывать реализацию super.Я скажу, что у меня никогда не было причин полностью переопределять свойство, но я не скажу, что в некоторых случаях это не может быть полезным инструментом, когда вам нужно полностью захватить существующее свойство.

Частная собственность
Это более полезно, чем вы считаете.Альтернативой частной собственности является простой старый ивар, с которым мы все знакомы.Если это ивар, который меняется с некоторой частотой, вы получите куски кода, которые выглядят следующим образом:

[_myIvar release], _myIvar = nil;

или:

[_myIvar release];
_myIvar = [someValue retain];

Хотя это не такВыглядит слишком плохо, такой шаблон управления памятью становится очень старым, очень быстрым.В качестве альтернативы, мы могли бы реализовать приведенный выше пример как частную собственность с сохранением семантики.Это означает, что, несмотря ни на что, нам просто нужно:

self.myIvar = someValue;

Что намного легче для глаз и пальцев через некоторое время.Вы правильно заметили, что, поскольку это свойство невидимо для остальной части вселенной, оно может быть случайно переопределено подклассом.Это неотъемлемый риск при разработке в Objective-C, но вы можете принять меры к тому, чтобы сделать этот риск чрезвычайно малым.Эти меры являются вариациями по изменению названия ваших частных свойств предсказуемым образом.Здесь можно идти бесконечными дорогами: например, вы делаете личную политику, заключающуюся в добавлении имен вашей частной собственности с инициалами и подчеркиванием.Для меня я бы получил что-то вроде mw_ivar и соответствующие -setMW_ivar: и -mw_ivar аксессоры.Да, статистически возможно, что кто-то может прийти и случайно переопределить это имя, но на самом деле это не так.Особенно, если у вас есть способ опубликовать свои практики для тех, кто может использовать ваш код.И я могу с уверенностью сказать, что Apple не обошла стороной и не создала частную собственность, которая была повреждена таким образом, поэтому вы также будете в безопасности на этом фронте.
Это просто стандартная практика.Вы правы, что это полезно, а также что это не опасно, поскольку свойство находится в заголовке.Любой, кто случайно отвергает это, должен винить только себя.

0 голосов
/ 13 апреля 2011

Хороший вопрос

  1. Использование это вы как разработчик должен знать, кто ты делать в этот момент и нужно добавить настройки для базового класса имущество. И так как вы знаете, что ты делаешь правильно позвонишь реализация super s, если у тебя есть веская причина не делать этого Решение не называть супер может быть вредно особенно в ситуациях где не знаешь как работает база класс реализован.

  2. Да, это вредно, но может быть избегать не чрезмерным использованием категорий и тщательно выбирая имя свойства или методы и рассмотреть префикс их.

  3. Да, вы правы, это хорошо для ограничение доступа к вашей собственности.

Пример для # 2

@interface UIView(PFXextended)
-(NSArray*)PFXGetSubviewsOfType:(Class)class;
@end
...