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

Question

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

Я не могу понять, почему правильно определить делегат со слабым указателем:

@property (nonatomic,weak) id delegate;

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

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

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

445 4

objective-c

4 ответов:

Comments

Ничего не найдено.

Barry Wark · Accepted Answer · 2011-12-09 22:19:42

причина, по которой объекты слабо сохраняют своих делегатов, заключается в том, чтобы избежать циклов сохранения. Представьте себе следующий сценарий: object a создает b и сохраняет его, а затем устанавливает себя как bс делегатом. a освобождается его владельцем, оставляя цикл сохранения, содержащий a и b. Это на самом деле очень распространенный сценарий. Рассмотрим контроллер представления, который владеет представлением и действует как делегат этого представления. В этом случае представление не должно удерживать контроллер - как матер правильная архитектура MVC и для предотвращения сохранения циклов.

kocodude · Accepted Answer · 2011-12-10 16:45:49

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

http://developer.apple.com/library/IOs/documentation/General/Conceptual/DevPedia-CocoaCore/Delegation.html

специально: "Главная ценность делегирования заключается в том, что оно позволяет легко настроить поведение несколько объектов в одном центральном объекте."

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

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

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

john · Accepted Answer · 2011-12-09 20:24:47

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

ранее вы бы определили свойство для такого делегата,
@property (nonatomic, assign) id delegate;
но в ARC, вы можете определить его таким образом,
@property (nonatomic, unsafe_unretained) id delegate;
или, для например, если у вас есть протокол с именем <MyObjectDelegate>, вы также можете определить делегата таким образом,
@property (nonatomic, weak) id <MyObjectDelegate> delegate;
другими словами, в ARC, если у вас есть протокол, вы можете объявить делегат weak. В противном случае, unsafe_unretained.

Jason · Accepted Answer · 2014-08-29 18:59:22

Как правило, если у нас есть два объекта, содержащие ссылки друг с другом, мы делаем "дочерний" объект в отношениях "родитель-дети" слабой ссылкой.
Для паттернов делегирования в iOS делегированный объект является родительским, поскольку нет необходимости, чтобы вызывающий делегат существовал без делегированного объекта. Например, у вас есть объект предложения с объектом делегата для метода sentenceShouldEnd. Объект абзаца является делегированным объектом для объекта предложения. Очевидно, что объект абзаца на самом деле является родителем, и в вашем объекте предложения вы должны сохранить свой делегат как слабую ссылку.
По вашему мнению, вы назначаете делегата себе, ваше понимание неверно. Мы никогда не должны назначать делегата самому себе. Почему вы покупаете билет самостоятельно, если считаете необходимым нанять агента, чтобы купить билет для вас? Вы говорите о двух совершенно разных понятиях. Когда вы определяете объект делегата как свойство, он использует слабую ссылку в объект определяется в(допустим, т. е. delegate объект-свойство). Делегат назначается, когда вы вводите A (скажем, в B), то, скорее всего, вы назначите A. делегат для себя, что является актом B. Вы видите здесь отношения родитель-ребенок?? У вас выделено памяти Для в Б. Вы держите в Б. не существует без Б. Вы не назначение делегата!!!!