¿Por qué a los delegados de Objective-C generalmente se les asigna la propiedad en lugar de retener?

Question

Estoy navegando a través del maravilloso blog mantenido por Scott Stevenson, y estoy tratando de comprender un concepto fundamental de Objective-C para asignar a los delegados la propiedad 'asignar' frente a 'retener'. Tenga en cuenta que ambos son iguales en un entorno recolectado de basura. Me preocupa sobre todo un entorno no basado en GC (p. Ej .: iPhone).

Directamente desde el blog de Scott:.

"La palabra clave de asignación generará un colocador que asigna el valor de la variable de instancia directamente, en lugar de copiar o retenerlo Este es el mejor para los tipos primitivos como NSInteger y CGFloat, o objetos que no posee directamente, como delegados ".

¿Qué significa que usted no posee directamente el objeto delegado? Normalmente retengo a mis delegados, porque si no quiero que se vayan al abismo, retener se encargará de eso por mí. Normalmente, elimino UITableViewController de su respectivo dataSource y también lo delego. También retengo ese objeto en particular. Quiero asegurarme de que nunca desaparezca, por lo que mi UITableView siempre tiene su delegado.

¿Alguien más puede explicar dónde/por qué estoy equivocado, entonces puedo entender este paradigma común en la programación de Objective-C 2.0 de usar la propiedad assign en los delegados en lugar de retener?

Gracias!

Answer 1

La razón de que evitar la retención delegados es que se necesita para evitar un ciclo de retener:

A crea B A presenta a sí misma como el delegado del B ... A es liberado por su dueño

Si B había retenido A, A no se liberaría, ya que B posee A, por lo tanto, nunca se llamaría al dealloc de A, causando que A y B fugas.

No debe preocuparse de que A se vaya porque posee B y así se deshace de él en dealloc.

Answer 2

Porque el objeto que envía los mensajes de delegado no posee el delegado.

Muchas veces, es al revés, como cuando un controlador se establece como el delegado de una vista o ventana: el controlador posee la vista/ventana, así que si la vista/ventana poseía su delegado, ambos objetos serían poseyéndonos el uno al otro. Esto, por supuesto, es un ciclo de retención, similar a una fuga con la misma consecuencia (los objetos que deberían estar muertos permanecen vivos).

Otras veces, los objetos son pares: ninguno posee el otro, probablemente porque ambos son propiedad del mismo tercer objeto.

De cualquier forma, el objeto con el delegado no debe retener su delegado.

(Hay al menos una excepción, por cierto. No me acuerdo de lo que era, y no creo que había una buena razón para ello.)

---

Adición (agregado 2012-05-19): en ARC, debe usar weak en lugar de assign. Las referencias débiles se configuran en nil automáticamente cuando el objeto muere, lo que elimina la posibilidad de que el objeto delegado termine enviando mensajes al delegado muerto.

Si se está alejando de ARC por alguna razón, al menos cambie assign propiedades que apuntan a objetos a unsafe_unretained, que hacen explícito que esta es una referencia no retenida pero no cero a un objeto.

assign sigue siendo apropiado para los valores que no son objetos tanto en ARC como en MRC.

Answer 3

Tenga en cuenta que cuando tiene un delegado asignado, es muy importante establecer siempre ese valor delegado en cero siempre que el objeto va a ser desasignado, por lo que un objeto siempre debe tener cuidado de no delegar referencias en dealloc si no lo ha hecho en otro lugar.

Answer 4

Una de las razones detrás de eso es evitar ciclos de retención. Solo para evitar el escenario donde A y B ambos objetos se referencian entre sí y ninguno de ellos se libera de la memoria.

Acutally assign es mejor para tipos primitivos como NSInteger y CGFloat, u objetos que no son de su propiedad, como los delegados.