Свойства в Objective C подробно и понятно

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

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

@interface Example : NSObject

@property NSObject *property;

@end

@implementation Example

@synthesize property;

@end

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

@interface Example : NSObject

@property (assign) NSObject *property;

@end

@implementation Example

@synthesize property;

@end

Что, в свою очередь, раскрывается так:

@interface Example : NSObject

{

@private

NSObject *property;

}

@property (assign) NSObject *property;

@end

@implementation Example

-(NSObject *)property

{

return property;

}

-(void)setProperty:(NSObject *)value

{

property = value;

}

@end

Фактически, при определении свойства через synthesize создается backend-поле с именем, аналогичным имени свойства. Это не всегда хорошо, потому что создает определенные проблемы с перекрытием имен, поэтому я рекомендую определять имя backend-свойства явно.

@interface Example : NSObject

@property (assign) NSObject *property;

@end

@implementation Example

@synthesize property = _property;

@end

Порождаемый в этом случае код аналогичен следующему:

@interface Example : NSObject

{

@private

NSObject *_property;

}

@property (assign) NSObject *property;

@end

@implementation Example

-(NSObject *)property

{

return _property;

}

-(void)setProperty:(NSObject *)property

{

_property = value;

}

@end

Однако, вы можете заметить, что assign-семантика мутатора для reference-объектов со счетчиком ссылок (а таковыми являются все объекты, производные от NSObject) это что-то не совсем правильное, ведь переменная после присваивания может быть уничтожена через release. Специально для этого, существует еще две семантики, которые поддерживаются synthesize – это retain и copy.

Принцип работы retain очевиден — при присваивании полю экземпляра объекта через мутатор, счетчик ссылок увеличивается на единицу. Однако, несколько неочевидно то, что происходит при доступе к объекту через аксесор. Рассмотрим простой пример.

@interface Example : NSObject

@property (retain) NSObject *property;

@end

@implementation Example

@synthesize property = _property;

@end

Порождает код:

@interface Example : NSObject

{

@private

NSObject *_property;

}

@property (retain) NSObject *property;

@end

@implementation Example

-(NSObject *)property

{

return _property;

}

-(void)setProperty:(NSObject *)property

{

[property retain];

[_property release];

_property = property;

}

@end

Обращаю ваше внимание на два крайне важных момента.

Момент первый. Доступ через аксесор не увеличивает счетчик ссылок. То есть экземпляр класса, который вы получили через аксесор, может быть уничтожен в любой момент, а значит — вы должны явно управлять его временем жизни.

Таким образом, данный код является неправильным.

Example *instance = [[Example alloc] init];

NSObject *value = instance.property;

// Do something with “value”

[instance release];

Проблема его заключается в том, что если в том месте, где вы do something, произойдет присваивание полю instance.property какого-либо значения, ваш экземпляр объекта в переменной value будет уничтожен в силу того, что в мутаторе свойства произойдет уменьшение счетчика ссылок до потенциального нуля.

Чтобы защититься от этого, необходимо при работе всегда явно брать ссылку.

Example *instance = [[Example alloc] init];

NSObject *value = [instance.property retain];

// Do something with “value”

[value release];

[instance release];

Момент второй. Определение свойства через synthesize не определяет деаллокатора свойства. Таким образом, в случае простейшего объекта без предопределенного метода dealloc мы получим утечку.

Таким образом, если мы определили свойство через synthesize — мы обязаны переопределять деаллокатор и писать в нем код, явно освобождающий объект. Это можно сделать одним из двух способов.

Способ первый — через присваивание свойству значения nil.

-(void)dealloc

{

self.property = nil;

[super dealloc];

}

Способ второй — через ручное уменьшение ссылки у backend-поля.

-(void)dealloc

{

[_property release];

[super dealloc];

}

Лично я предпочитаю второй способ, но рекомендую первый — он гораздо понятнее и лучше читается.

Момент третий. Любое присваивание backend-полю через мутатор, определенный с retain, увеличивает счетчик ссылок. Однако, если вы присваиваете значение напрямую, например, в конструкторе — счетчик ссылок увеличен не будет.

Таким образом, код

-(id)initWithProperty:(NSObject *)property

{

self = [super init];

if(!self)

return nil;

self.property = property;

return self;

}

Является совершенно корректным. А код

-(id)initWithProperty:(NSObject *)property

{

self = [super init];

if(!self)

return nil;

_property = property;

return self;

}

Ужасен, так как число ссылок не увеличивается, а значит — вы неминуемо получите SIGABRT где-нибудь в процессе выполнения приложения. Правильно делать так:

-(id)initWithProperty:(NSObject *)property

{

self = [super init];

if(!self)

return nil;

_property = [property retain];

return self;

}

И упаси вас Б-г от такого кода:

-(id)initWithProperty:(NSObject *)property

{

self = [super init];

if(!self)

return nil;

self.property = [property retain];

return self;

}

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

Нередко, впрочем, она компенсируется двойным освобождением.

-(id)initWithProperty:(NSObject *)property

{

self = [super init];

if(!self)

return nil;

self.property = [property retain];

return self;

}

-(void)dealloc

{

[self.property release];

self.property = nil;

[super dealloc];

}

Так писать, конечно, можно, но не нужно.

Кроме того, существует возможность определить для synthesize семантику копирования в мутаторе. Выглядит и работает она практически так же, как семантика взятия ссылки, но в отличие от последней вызывает не retain, а copy, что требует от объекта определенных телодвижений для поддержки ее работы.

Во-первых, следует помнить, что объект должен поддерживать протокол NSCopying. Лучше делать это явно, чтобы скинуть проверку ошибок несоответствия на компилятор.

@interface Example : NSObject

@property (copy) NSObject<NSCopying> *property;

@end

Теперь при определении свойства через synthesize будет сгенерирован код:

@implementation Example

-(NSObject<NSCopying> *)property

{

return _property;

}

-(void)setProperty:(NSObject<NSCopying> *)property

{

NSObject<NSCopying> *pCopy = [property copy];

[_property release];

_property = pCopy;

}

@end

Осталось только определить деаллокатор, который бы освобождал ссылку на копию объекта — и дело сделано.

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

-(UIView *)view

{

if(!_view)

[self loadView];

return [[_view retain] autorelease];

}

На данном примере можно осознать, что мутатор и аксесор свойства — это обычные методы, которые могут вызывать любые другие. Так, например, в данном случае аксесор проверяет, было ли загружено представление, и если нет — загружает его, после чего увеличивает счетчик ссылок на единицу и отдает объект в autorelease pool.

Чем хорош подход с пулом? Тем, что он позволяет застраховаться от ошибок, когда мы не сделали retain при получении значения свойства через аксессор. Объект в пуле освободится только при выходе из текущего user code стека вызова, а значит у нас есть определенная гарантия того, что объект не освободится прежде, чем мы закончим с ним работать.

Почему такую семантику не определяет synthesize? Дело в том, что она требует активного autorelease pool в текущем потоке, чего в общем случае гарантировать нельзя, а закладываться на необходимость его определения везде и всюду — это значит тратить лишние ресурсы на поддержание ненужной инфраструктуры.

Однако, следует помнить, что в общем случае при получении и присваивании свойства может выполняться произвольный код, а потому имеет смысл опираться только на публичный контракт свойства. А именно, при получении через аксесор свойства любого объекта ссылочного типа необходимо сделать retain. Ну и release в конце.