Метод dealloc должен высвобождать свои собственные переменные экземп-ляра до использования super для ликвидации самого объекта. Объект становится недействительным после того, как освобождена память объекта (dealloc).

Чтобы избежать утечки памяти для класса AddressCard, нужно также внести изменения в методы setName: и setEmail: и освобождать память, которая исполь-зуется объектами, сохраненными в их переменных экземпляра. Если кто-то изменяет имя на карточке, мы должны освободи ть память, которая используется старым именем, прежде чем заменить его новым именем. Дцля адреса элек- тронной почты мы тоже должны освободить память, которая используется для этого адреса, прежде чем заменить его новым.

Ниже приводятся новые методы setName: и setEmail: для класса, который пра-вильно управляет памятью. -(void) setName: (NSString *) theName { [name release]; name = [[NSString alloc] initWithString: theName]; } -(void) setEmail: (NSString *) theEmail { [email release]; email = [[NSString alloc] initWithString: theEmail]; }

Мы можем отправлять сообщение nil-объекту; поэтому выражения с сооб-щениями [name release];

и [email release];

допустимы, даже если name или email не были заданы ранее. Синтезируемые методы AddressCard

Теперь, когда описан подходящий способ написания методов доступа setName: и setEmail:, мы можем вернуться к началу и позволить самой системе сгенерировать методы доступа (accessor method). Рассмотрим второй вариант файла секции interface AddressCard. #import <Foundation/NSObject.h> #import <Foundation/NSString.h> @interface AddressCard: NSObject { NSString *name; NSString *email; } @property (copy, nonatomic) NSString *name, *email; -(void) print; @end

В строке @property (copy, nonatomic) NSString *name, *email;

содержатся атрибуты сору и nonatomic для свойств (property). Атрибут сору указывает, что нужно создать копию переменной экземпляра в ее методе-установши- ке (setter), как мы делали в предыдущей версии. Действие по умолчанию — не создавать копию, а просто выполнить присваивание (атрибут по умолчанию assign), что является неверным подходом, как мы выяснили выше.

Атрибут nonatomic указывает, что метод-получатель (getter) не должен удер-живать (retain) или автоматически высвобождать (autorelease) переменную экземпляра, прежде чем возвратить ее значение. В главе 18 эта тема описывается более подробно.

Программа 15.9 — это новый файл секции implementation AddressCard, кото-рый указывает, что методы доступа будут синтезированы. #import "AddressCard.h" @implementation AddressCard @synthesize name, email; -(void) print { NSLog (@"============================="); NSLog (@"| |"); NSLog (@"| %-31s |", [name UTF8String]}; NSLog (@"| %-31s |", [email KTF8String]); NSLog (@"| |"); NSLog (@"| |"); NSLog (@"| |"); NSLog (@"| O O |"); NSLog (@"============================="); } @end

Мы оставляем вам в качестве упражнения проверку того, что это новое оп-ределение AddressCard с синтезируемыми методами доступа работает с тестовой программой, показанной в программе 15.9.

Теперь добавим еше один метод в класс AddressCard. Предположим, что мы хотим задавать поля name и email с помощью одного вызова. Чтобы сделать это, мы добавим новый метод setName:andEmail:. Он имеет следующий вид. -(void) setName: (NSString *) theName andEmail: (NSString *) theEmail { self.name = theName; self.email = theEmail; }

Полагаясь на синтезируемые методы-установщики для задания соответству-ющих переменных экземпляра (вместо их непосредственного задания внутри самого метода), мы повышаем уровень абстрагирования, делая программу более независимой от внутренних структур данных. Мы также используем свойства синтезируемого метода; в данном случае это копирование (сору) вместо присваивания (assign) значения переменной экземпляра.

Этот метод тестируется в программе 15.9. #import <Foundation/Foundation.h> #import "AddressCard.h" int main {int argc, char *argv[]) { NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init]; NSString *aName = @ "Julia Kochan"; NSString *aEmail = @"jewls337@axlc.com"; NSString *bName = @"Tony lannino"; NSString *bEmail = @"tony.iannino@techfilness.com"; AddressCard *card1 = [[AddressCard alloc] init]; AddressCard *card2 = [[AddressCard alloc] init]; [cardl setName: aName andEmail: aEmail]; [card2 setName: bName andEmail: bEmail]; [cardl print]; [card2 print]; [cardl release]; [card2 release]; [pool drain]; return 0; }

Вывод программы 15.9 ======================================== | | | Julia Kochan | | jewls337@axlc.com | | | | | | | | O O | ======================================== ======================================== | | | Tony lannino | | tony.iannino@techfilness.com | | | | | | | | O O | ========================================

Класс AddressCard, казалось бы, действует правильно. Но как быть, если нужно работать с большим числом адресных карточек (объектов AddressCard)? Видимо, имеет смысл собрать их вместе. Именно это мы и сделаем, определив новый класс AddressBook (Адресная книга). В классе AddressBook будет храниться имя адресной книги и набор адресных карточек в объекте-массиве. Начнем со средств создания новой адресной книги, добавления в нее новых адресных карточек, определения числа содержащихся в ней записей и вывода списка ее содержимого. Затем нам потребуются средства поиска в этой адресной книге, удаления записей, редактирования существующих записей, их сортировки и создания копии содержимого.