Tengo una aplicación que estoy escribiendo que usa únicamente @properties. No he declarado ningún ivar en ninguno de mis archivos de clase. Según tengo entendido, ya no se necesitan ivars con la introducción de @property. ¿Estoy codificando según las mejores prácticas? ¿Esto terminará mordiéndome en el trasero proverbial a largo plazo? He estado leyendo comentarios mixtos sobre lo que es "correcto" e "incorrecto" ...¿Debo usar ivars en Objective-C?
En general, tampoco declaro ivars.
A menudo usaré
Y siempre dejo que el compilador sintetice automáticamente el ivar con el prefijo @synthesize foo = foo_; para evitar el acceso directo cuando me refiero a un método intermedio o viceversa.
_ (que impide el acceso directo accidental, según la frase
golpeada
).
Y, como dijo Caleb, todavía hay ivars flotando, simplemente no los declaras explícitamente a menos que realmente quieras (que, realmente, no como ivars expuestos en los encabezados no son útiles para clientes de la clase, si su API está diseñada apropiadamente).
También me parece que el alboroto sobre "usar solo acceso directo en init/dealloc, usar setter/getter en cualquier otro lugar" es en gran medida exagerado y, por lo tanto, simplemente use el setter/getter en todas partes. La realidad es que si tiene observadores durante la inicialización/desasignación, ya está manchado; el estado del objeto es, por definición, indefinido durante la construcción/destrucción y, por lo tanto, un observador no puede razonar correctamente sobre el estado.
Como Caleb señala, otra razón para utilizar el acceso Ivar directa en init/dealloc es evitar las subclases que implementan la lógica setter/getter personalizado que puede vomitar debido al estado indefinido del objeto durante init/dealloc.
Si bien esto puede ser cierto, considero una desagradable falla arquitectónica implementar implementadores/ejecutores con comportamiento personalizado. Hacerlo es frágil y hace que sea mucho más difícil refactorizar el código a lo largo del tiempo. Además, dicho comportamiento personalizado a menudo tendrá dependencia de otro estado dentro del objeto y esa dependencia lleva a ordenar dependencias en los cambios de estado que no están del todo reflejados por la aparente declaración simple @property.
I.e. Si sus setters y getters están escritos de manera tal que foo.bar = bad; no pueden ejecutarse en any time on foo, entonces su código es reventado.
Me parece que si no declaro explícitamente ivars, no puedo inspeccionar sus valores en el depurador. Así que he tomado el hábito de declarar explícitamente ivars para los tipos de valor. –
@ohhorob ¿Dónde dicen eso? No es que no esté de acuerdo, siempre pensé que ese era el caso. Pero he buscado una declaración a tal efecto en los documentos algunas veces recientemente y salió vacía. Si usted sabe dónde está, ¡por favor comparta! – Caleb
@Emile - Ahhh! Eso es genial de saber Siempre me he preguntado por qué en algunas aplicaciones puedo ver valores en el depurador y otras no. Quizás esto ESTÁ ligado a si se declara o no un ivar. Debo investigar esto de inmediato! =) – ElasticThoughts
Usar iVars ciertamente no es incorrecto, sin embargo, las mejores prácticas ahora lo presionan para usar @property.
No es tanto que las variables de instancia no sean necesarias. Es solo que las declaraciones de instancia no son necesarias. Dada una propiedad y una instrucción @synthesize, el compilador se encargará de crear la variable de instancia junto con los métodos de acceso apropiados.
No hay nada malo con el uso exclusivo de propiedades. Simplifican la gestión de la memoria. Tampoco hay nada de malo en usar iVars sin propiedades, si eso es lo que quieres. Si desea utilizar propiedades pero no desea anunciar los accesos al resto del mundo (es decir, mantener la encapsulación), considere declarar sus propiedades no públicas en una extensión de clase (básicamente una categoría anónima en su archivo de implementación).
Un lugar donde es posible que desee utilizar un ivar es cuando desea declarar una propiedad protegida. Usted declara la propiedad en el archivo .m para una clase y declara su ivar correspondiente en .h con la directiva @protected.Esto le permitirá tener un acceso protegido en la subclase. No hay alternativa para el acceso protegido a los miembros.
Tenga en cuenta que si tiene una declaración de ivar y una declaración de propiedad para el mismo ivar, su código no es SECO (no se repita). –
La respuesta a esta pregunta depende, entre otras cosas, de cuándo hizo la pregunta. El enfoque "ideal" aquí ha sido un objetivo móvil. –