Duplicar posible:
What describes @property(…) best? What's that actually good for?¿Por qué debería usar @properties?
Si declara una variable en mi interfaz de clase, puedo utilizar dicha variable en cualquier parte de mi clase. Increíble.
Si uso @property (retain) Something *myVar; puedo acceder a esa variable con self.myVar ... Pero, ¿cuál es la diferencia? ¿Hay una buena razón por la que debería usar un método u otro?
Respuesta corta: Encapsulación de la gestión de la memoria.
Respuesta más larga: debe establecer la propiedad de un objeto si desea usarlo más adelante. Si desea usarlo más adelante, necesitará una referencia para poder hacerlo, y un buen lugar para mantener esa referencia es en una variable de instancia.
Usted podría manejar las reclamaciones de propiedad (es decir, retiene y libera) cada vez que se asigna un nuevo valor a eso, sino que dejaría una gran cantidad de código repetitivo repetitivo y propensos a problemas dispersos por todo el lugar, como las cerezas en un pastel de frutas. Ese tipo de desastre es diabólicamente difícil de depurar cuando (no si) algo sale mal. Por lo tanto, es mucho mejor ajustar ese código en los métodos de acceso, para que pueda escribirlo una vez y luego olvidarse de él.
Pero los métodos de acceso son en su mayoría repetitivos, por lo que usamos declaraciones de propiedades para crearlos automágicamente, en lugar de escribirlos a mano.
Editar: Memory Management Guide de Apple proporciona una gran cantidad de detalles acerca de lo que los métodos de acceso generados por @property hacen detrás de las escenas.
¿Entonces el primer método que mencioné no establece la propiedad de un objeto y por lo tanto podría perderlo en el futuro? Supongo que usaré propiedades para todo = /. Una última cosa: si uso self.myProperty = nil en el método Dealloc (cuando ya no lo necesito) estoy bien, ¿verdad? No tengo que decir [lanzamiento de self.myProperty] ni nada? – Voldemort
No, la propiedad se establece creando un objeto con + alloc, -copy, o -mutableCopy, o enviándole un mensaje -retain. No importa cómo establezca la propiedad, debe renunciar mediante el envío de un mensaje de liberación. Y ahí está el problema: cada vez que asigna un nuevo valor a su variable de instancia, necesita liberar el antiguo, y debe asegurarse de que todas estas afirmaciones de propiedad permanezcan equilibradas. –
Es más fácil hacerlo evitando los métodos de creación que establecen propiedad, o usando -auto cuando debe usarlos, y simplemente dejando que la asignación de propiedad se encargue del resto. –
El uso de @property para acceder a sus ivars, hace que gran parte del código repetitivo de liberar y retener objetos para usted. No tienes que usarlos. Son solo muchos tutoriales lo que simplifica a las personas que son nuevas en la plataforma.
Si utilizo @property (retener) Algo * myVar; Puedo acceder a esa variable con self.myVar ... Pero, ¿cuál es la diferencia?
@property (retain) Something *myVar;
// this property declaration declares:
- (Something *)myVar;
// and
- (void)setMyIvar:(Something *)arg;
// and is accessible by dot syntax.
// it also declares and/or documents how the ivar is managed (copy, retain, etc.)
en uso:
// direct access to the ivar. zero additional overhead (with regard to accessing the ivar)
[myVar message];
// properties used with dot syntax invoke the accessor. therefore,
[self.myVar message];
// is the same as:
[[self myVar] message];
las propiedades de la propiedad también se dan instrucciones al compilador cuanto a la forma de sintetizar un descriptor de acceso.
¿Hay alguna buena razón para usar uno u otro método?
en init y dealloc, acceda al ivar directamente - le interesa la inicialización y la limpieza de los ivars del objeto y no le importan las subclases. el uso de propiedades aquí también puede introducir errores o un comportamiento indefinido.
para otros casos, es decir, cuando el objeto está en un estado totalmente construido, siempre debe usar el acceso para coherencia.si una subclase anula un descriptor de acceso, el acceso directo del ivar podría romper los diseños.
si desea evitar esto, haga que el ivar sea privado y no declare una propiedad para él. si declara una propiedad para ella, entonces documente que es privada; Por lo general, escribiré @property (retain) Something * private_myIvar; en este caso. en este caso, es conveniente usar una propiedad para sintetizar la administración de la memoria del ivar.
cuando el ivar es privado, tiene acceso total a él. es seguro acceder directamente o por propiedad privada. de lo contrario, suponga que debe usar el descriptor de acceso.
si myIvar se declara privado y se creará solo durante la inicialización, puede evitar declarar las propiedades por completo. esto reducirá la sobrecarga de tiempo de ejecución (si eso es crítico). la sobrecarga de mensajería, los ciclos de retención/liberación y los atómicos requerirán (naturalmente) más tiempo de ejecución. por lo que se puede pasar por alto para mejorar el rendimiento.
visibilidad/mantenimiento. a veces, es mucho menos mantenimiento/implementación para ocultar un ivar de la interfaz. en otros casos, el ivar es un detalle de implementación de la clase y no debe formar parte de la interfaz pública. en tales casos, considere la posibilidad de hacerlo privado (hay algunas formas de justificar esto en objc).
Creo que tiene que ver con si desea o no crear métodos getter/setter, pero no me cite sobre eso. Es de conocimiento común entre los veteranos del cacao, estoy seguro de que alguien responderá esto pronto :) –