Может ли пропуск объявления свойств для свойств вызвать проблемы или утечки?

Question

Я начал изучать и разрабатывать для iOS4, поэтому я просто пропустил старое соглашение об объявлении ivar и начал использовать чистые свойства, даже не объявляя ivars. Все прошло хорошо, я даже выпустил свое первое домашнее приложение в магазине приложений. Но потом в моей компании разработчиков ребята сказали мне, что они все еще используют старое соглашение и объявляют ивары с подчеркнутыми именами, используют свойства и синтезируют их (см. Пример в конце). Они также сказали, что они используют свойства только тогда, когда требуется внешний доступ к ivars, а для внутреннего доступа они используют прямой ivars (для пользовательских классов). Мне сказали, что они делают это, потому что они испытывают некоторые странные утечки, которые иногда появляются при использовании пользовательских классов и обнулении их свойств в viewDidUnload (потому что установка nil для свойств иногда не освобождает эти объекты ivar)

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

@interface ContactModel : NSObject {

  NSString *_firstName;
}

@property (nonatomic, retain) NSString *firstName;

@end

@implementation ContactModel

@synthesize firstName = _firstName;

-(void)dealloc{
  [_firstName release];
  [super dealloc];
}
@end

Следует также отметить, что Apple по-прежнему использует этот старый стиль объявления при создании файла класса делегата основного приложения и синтезирует window = _window. Хм, в настоящее время я немного смущен тем, какое соглашение я должен принять, поэтому любые идеи приветствуются:)

Answer 1

Я предпочитаю «старый способ», потому что я предпочитаю последовательность и (что более важно) инкапсуляцию.

Согласованность

лично, я просто хочу хорошее представление оразмер и сложность объекта, если посмотреть на одно место.

пример: когда вы реализуете dealloc, предпочитаете ли вы ссылаться на несколько мест?не я.это сложнее, чем необходимо.я не хочу выяснять, что мне нужно очистить, создав набор из всех ivars и свойств.одних свойств недостаточно, потому что они также оказываются в разных местах (интерфейс, частные категории) = \

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

Инкапсуляция

, когда вы видите программу, в которой большинство свойств иваров / объектов видны и читаются/ доступный для записи ... это не OOD, это беспорядок.когда вам нужно описать это вежливо, это анти-паттерн 'Object Orgy' .к сожалению, это довольно часто встречается в программах objc (частично из-за ограничений языка / времени выполнения).

ivars с префиксами подчеркивания: лично я не использую это соглашение в objc.если так написан их код, то продолжайте с ним (ничего страшного).

Они также сказали, что они используют свойства только тогда, когда нужен внешний доступ к ivars, и для внутреннего доступа онииспользуйте прямые ивары (для пользовательских классов).

вправо - вот где попытки инкапсуляции входят в картину.продолжайте в том же духе и принимайте правильную инкапсуляцию.

Мне сказали, что они делают это, потому что у них были странные утечки, которые иногда возникали при использовании пользовательских классов и обнулении их свойств в viewDidUnload (потому чтоустановка свойств в nil иногда не высвобождает эти объекты ivar)

в идеале, они дадут вам лучшее объяснение (и дойдут до корня конкретной проблемы в то время).

вполне вероятно, что их таинственная программа (программы) недостаточно четко отличалась от ее участников (данных), интерфейса и выполнения.когда они совпадают, нередко теряют право собственности.этот случай является общим признаком дезорганизации и / или реализации, выходящей за рамки ожиданий.если вы правильно организовываете / пишете классы, слежение за ivar / property очень просто (по-видимому, они добиваются прогресса, поддерживая инкапсуляцию).кроме того, защищенный является видимостью по умолчанию;я рекомендую использовать private как ваше значение по умолчанию.

Просто интересно, почему я должен беспокоиться об использовании объявления ivar, когда использование свойств и synthesize делает все необходимые вещи.Я даже могу получить доступ к иврам напрямую, используя их имена без self в dealloc.Итак, есть ли у кого-нибудь проблемы с этим, или многие из вас все еще придерживаются старой декларации декларации?

• программа, которая хорошо разработана, не состоит из больших двоичных объектов данных (с публичным доступом или свойством)доступные переменные).
• в большинстве случаев состояние (например, ivars) не должно напрямую отображаться на интерфейс.
• держать ваши данные и имплементации хорошо скрытыми от других.
• даже 'Свойства private могут быть легким источником ошибок (их селекторы могут быть выполнены или переопределены).
• , когда по умолчанию используется private, а ivar действительно недоступен извне, вы можете уменьшить lot сложности.

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

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

делает ваши программы устойчивыми к ошибкам пользователей, скрывая то, что вы можете, и согласовывая их со стилем вашей команды.1061 *

(технически есть несколько дополнительных преимуществ, которые я не буду здесь подробно описывать)

Answer 2

В современной среде выполнения вам не нужно объявление ivar, но синтез a = _a по-прежнему полезен для различения self.a (средства доступа) и _a (прямой доступ).Если у @ property / @ synthesize произошла утечка, я думаю, что мы должны знать об этом.

AFAIK, использующий вместо свойств свойства ivars, полезен только в том случае, если вы хотите иметь доступ с защитой @ (доступ только к подклассам) или поддерживать старую среду выполнения.

В dealloc вы должны освободить свойство напрямую, независимо от того, используете ли вы ivar декларацию и @properties, и при желании вы можете nil или , а не .