Если вы установите делегат на нуль в классе с помощью делегата или самого класса

Если класс A использует класс B, а класс A является делегатом класса B, нормально ли, если делегат установлен в nil в классе B dealloc? Я видел, что код обычно сбросил делегат на нуль внутри класса A dealloc, но не был уверен, что реальная разница делает это так или иначе.

например. Это обычный способ:

// somewhere in class A

- (void) someFunc {
  self.b = [[B alloc] init];
  self.b.delegate = self;
}

- (void) dealloc {
  self.b.delegate = nil;
  [self.b release];
}

Ответ 1

Да, вы должны установить свойство delegate класса B равным нулю в classA dealloc.

Это не проблема управления памятью, потому что свойства делегата должны быть отмечены как назначаемые, а не сохраняемые, чтобы избежать циклов сохранения (иначе dealloc никогда не будет вызываться). Проблема в том, что иначе classB может передать класс сообщения A после его освобождения.

Например, если классB имеет вызов delagate, чтобы сказать "быть скрытым", а classB освобождается сразу после класса A, он будет сообщать об уже отлученном классе A, вызывающем сбой.

И помните, вы не всегда можете гарантировать порядок dealloc, особенно если они автореализовываются.

Итак, да, нуль из свойства делегата в classA dealloc.

Ответ 2

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

@property (assign) id<BDelegate> delegate;

Вам не нужно выполнять какое-либо управление памятью в dealloc, так как счет сохранения не набит, когда вы вызываете self.b.delegate = self; - в отличие от использования (сохранения) или (копирования)

Имеют смысл? Было бы неплохо установить делегат на нуль, но в чем смысл?

Ответ 3

Во-первых, несколько наблюдений...

Вы забыли позвонить [super dealloc] в конце своего собственного метода dealloc.
Поскольку "a" создан "b", и если никакие другие объекты не сохранили "b", нет смысла в деле делегирования делегата в -dealloc, так как "b" все равно будет уничтожено. Если возможно, что другие объекты имеют ссылку на "b" (что означает, что он может пережить "a" ), установите делегат на нуль.
Объектом 'b' должен быть тот, кто позаботится о своем делетете в своем собственном -dealloc, если это необходимо. (Как правило, делегат не сохраняет делегата.)
Избегайте использования свойств в -init... и -dealloc-методах - Apple отпугивает это и не без оснований. (Не только это может иметь неожиданные побочные эффекты, но также может вызвать более неприятные, более сложные проблемы.)
Использование свойств (через синтаксис точек), когда вам не нужно невидимо добавлять дополнительную работу. Например, self.b.delegate = self эквивалентен [[self getB] setDelegate:self] - это просто синтаксический сахар, который делает его похожим на то, что вы напрямую обращаетесь к ivar, но на самом деле нет.
Использование свойств без понимания того, что они делают, может привести к проблемам. Если self.b сохраняет значение (для свойства задано значение "назначить" ), у вас есть утечка памяти на ваших руках.

Вот как я, вероятно, напишу его:

- (void) someFunc {
  b = [[B alloc] init];
  b.delegate = self; // or [b setDelegate:self];
}

- (void) dealloc {
  b.delegate = nil;
  [b release];
  [super dealloc];
}