Чому делегатам Objective-C зазвичай присвоюється властивість замість збереження?

Я переглядаю чудовий блог, який підтримує Скотт Стівенсон, і я намагаюся зрозуміти основоположну концепцію Objective-C щодо присвоєння делегатам властивості "призначити" проти "зберегти". Зауважте, обидва однакові у сміттєвому середовищі. Мене найбільше хвилює середовище, що не базується на GC (наприклад, iPhone).

Безпосередньо з блогу Скотта:

"Ключове слово присвоїти буде генерувати сеттер, який присвоює значення змінній екземпляру безпосередньо, а не копіює або зберігає його. Це найкраще для примітивних типів, таких як NSInteger і CGFloat, або об'єктів, якими ви безпосередньо не володієте, наприклад, делегатів."

Що означає, що ви безпосередньо не володієте об'єктом делегата? Я, як правило, затримую своїх делегатів, тому що якщо я не хочу, щоб вони відходили в безодню, утримуватимуться, щоб подбати про це за мене. Я зазвичай абстрагую UITableViewController подалі від відповідного джерела даних і також делегую. Я також зберігаю саме цей предмет. Я хочу переконатися, що він ніколи не зникає, тому мій UITableView завжди має свого делегата.

Чи може хтось далі пояснити, де / чому я помиляюся, тож я можу зрозуміти цю загальну парадигму в програмуванні Objective-C 2.0 щодо використання властивості присвоєння делегатам замість збереження?

Дякую!

Причина того, що ви уникаєте утримувати делегатів, полягає в тому, що вам потрібно уникати циклу збереження:

A створює B A встановлює себе делегатом B ... A випускається його власником

Якби B утримував A, A не було б звільнено, оскільки B є власником A, таким чином, угода A ніколи не зателефонується, що призведе до витоку і A, і B.

Ви не повинні турбуватися про те, що йде геть, тому що він є власником B і, таким чином, позбавляється від нього у взаємодії.

Оскільки об'єкт, що надсилає повідомлення про делегат, не є власником делегата.

Багато разів - це навпаки, як коли контролер встановлює себе як делегат подання чи вікна: контролеру належить перегляд / вікно, тому якби перегляд / вікно володів його делегатом, обидва об'єкти мали б один одного. Це, звичайно, цикл утримування, подібний до витоку з тим же наслідком (предмети, які повинні бути мертвими, залишаються живими).

В іншому випадку об'єкти є однолітками: жоден не володіє іншим, ймовірно, тому, що вони обидва є одним і тим же третім об'єктом.

У будь-якому випадку об'єкт з делегатом не повинен зберігати свого делегата.

(До речі, є принаймні один виняток. Я не пам’ятаю, що це було, і я не думаю, що це було вагомою причиною.)

Додаток (додано 2012-05-19): Під ARC вам слід використовувати weakзамість assign. Слабкі посилання встановлюються nilавтоматично, коли об’єкт гине, виключаючи ймовірність того, що об’єкт, що делегує, в кінцевому підсумку надсилає повідомлення мертвому делегату.

Якщо ви чомусь тримаєтесь подалі від АРК, принаймні змініть assignвластивості, які вказують на об’єкти unsafe_unretained, які роблять очевидним, що це невідоме, але не нульове посилання на об'єкт.

assign залишається придатним для не об’єктних значень як для ARC, так і для MRC.

Зауважте, що коли у вас є присвоєний делегат, дуже важливо завжди встановлювати це значення делегу на нуль, коли об'єкт буде розміщений - тому об'єкт завжди повинен бути обережним, щоб звести посилання делегата в dealloc, якщо він не має це робиться в інших місцях.

Однією з причин цього є уникати циклів утримування. Просто щоб уникнути сценарію, коли A і B обидва об'єкта посилаються один на одного, і жоден з них не звільняється з пам'яті.

Акутально призначити найкраще для примітивних типів, таких як NSInteger та CGFloat, або об'єктів, якими ви безпосередньо не володієте, наприклад, делегатів.