Что вредит переопределению свойств в Objective-C?

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

Вы объявляете свойство с тем же именем и тем же атрибутом его суперкласса "(поскольку, если вы измените атрибут вы можете получить компилятор предупреждение). И вы можете синтезировать с иваром, который вы создаете. какой использование этого? Или какой вред может ли это сделать?
Если суперкласс объявляет свойство в расширении класса (категория без имени), то это может и не быть в файле заголовка. Если вы не знать это свойство из заголовка файл, вы можете объявить одно и то же имя свойство с каким атрибутом или класс, который вы хотите. Но метод setter/getter переопределит те для этого "секретного имущества". Я думаю, что это может только нанести вред. Но так как вы не знаете из заголовка файл, как вы можете избежать этого?
Вы можете объявить свойство в файле заголовка как "readonly" и в расширение класса обновляет его как "читай пиши". Я думаю, это ситуация, что он может сделать добро.

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

Ответ 1

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

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

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

[_myIvar release], _myIvar = nil;

или

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

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

self.myIvar = someValue;

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

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

Ответ 2

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

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

Пример для # 2

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