Perché ai delegati Objective-C di solito viene assegnata la proprietà anziché trattenerla?

Sto navigando attraverso il meraviglioso blog gestito da Scott Stevenson e sto cercando di capire un concetto fondamentale di Objective-C di assegnare ai delegati la proprietà 'Assegna' vs 'Conserva'. Nota, entrambi sono uguali in un ambiente di raccolta rifiuti. Mi occupo principalmente di un ambiente non basato su GC (ad es. IPhone).

Direttamente dal blog di Scott:

"La parola chiave assegnata genererà un setter che assegna direttamente il valore alla variabile di istanza, piuttosto che copiarlo o conservarlo. Questo è meglio per tipi primitivi come NSInteger e CGFloat, o oggetti che non possiedi direttamente, come i delegati."

Cosa significa che non possiedi direttamente l'oggetto delegato? In genere trattengo i miei delegati, perché se non voglio che vadano via nell'abisso, si occuperà di me. Solitamente estraggo UITableViewController dal rispettivo DataSource e delegare anche. Conservo anche quel particolare oggetto. Voglio assicurarmi che non scompaia mai, quindi il mio UITableView ha sempre il suo delegato in giro.

Qualcuno può spiegare ulteriormente dove / perché mi sbaglio, così posso capire questo paradigma comune nella programmazione di Objective-C 2.0 di usare la proprietà assegnato sui delegati invece di conservare?

Grazie!

Il motivo per cui si evita di trattenere i delegati è che è necessario evitare un ciclo di mantenimento:

A crea B A si imposta come delegato di B ... A viene rilasciato dal suo proprietario

Se B avesse trattenuto A, A non verrebbe rilasciato, poiché B possiede A, quindi il dealloc di A non verrebbe mai chiamato, causando la fuga di A e B.

Non dovresti preoccuparti che A se ne vada perché possiede B e quindi se ne sbarazza in dealloc.

Perché l'oggetto che invia i messaggi delegato non possiede il delegato.

Molte volte, è il contrario, come quando un controller si imposta come delegato di una vista o finestra: il controller possiede la vista / finestra, quindi se la vista / finestra possedesse il suo delegato, entrambi gli oggetti si sarebbero posseduti l'un l'altro. Questo, ovviamente, è un ciclo di mantenimento, simile a una perdita con la stessa conseguenza (gli oggetti che dovrebbero essere morti rimangono vivi).

Altre volte, gli oggetti sono peer: nessuno dei due possiede l'altro, probabilmente perché entrambi sono di proprietà dello stesso terzo oggetto.

In entrambi i casi, l'oggetto con il delegato non deve conservare il proprio delegato.

(A proposito, c'è almeno un'eccezione. Non ricordo di cosa si trattasse e non credo che ci fosse una buona ragione per farlo.)

Addendum (aggiunto il 19/05/2012): in ARC, è necessario utilizzare weakinvece di assign. I riferimenti deboli vengono impostati nilautomaticamente su quando l'oggetto muore, eliminando la possibilità che l'oggetto delegante finisca per inviare messaggi al delegato morto.

Se stai lontano da ARC per qualche motivo, modifica almeno le assignproprietà che puntano agli oggetti unsafe_unretained, il che rende esplicito che si tratta di un riferimento non mantenuto ma azzerante di un oggetto.

assign rimane appropriato per i valori non oggetto sia in ARC che in MRC.

Si noti che quando si dispone di un delegato assegnato, è molto importante impostare sempre quel valore del delegato su zero ogni volta che l'oggetto verrà deallocato, quindi un oggetto dovrebbe sempre fare attenzione a azzerare i riferimenti delegati nel dealloc se non ha fatto altrove.

Uno dei motivi alla base di ciò è quello di evitare cicli di mantenimento. Solo per evitare lo scenario in cui A e B fanno riferimento a entrambi gli oggetti e nessuno di essi viene rilasciato dalla memoria.

Assegnare acutamente è la cosa migliore per tipi primitivi come NSInteger e CGFloat, o oggetti che non possiedi direttamente, come i delegati.