Propiedades bajo ARC: ¿Siempre o solo público?

Después de leer un artículo humildemente llamado "Los Mandamientos del Código: Mejores Prácticas para la Codificación de Objective-C" por Robert McNally hace poco menos de dos años, adopté la práctica de usar propiedades para casi todos los miembros de datos de mis clases de Objective-C ( el 3er mandamiento a partir de mayo de 2012). McNally enumera estas razones para hacerlo (mi énfasis):

1. Las propiedades imponen restricciones de acceso (como solo lectura)
2. Las propiedades hacen cumplir la política de administración de memoria (fuerte, débil)
3. Las propiedades brindan la oportunidad de implementar de manera transparente setters y getters personalizados.
4. Las propiedades con setters o getters personalizados se pueden usar para aplicar una estrategia de seguridad de subprocesos.
5. Tener una única forma de acceder a las variables de instancia aumenta la legibilidad del código.

Puse la mayoría de mis propiedades en categorías privadas, por lo que los números 1 y 4 generalmente no son problemas con los que me encuentro. Los argumentos 3 y 5 son más "suaves", y con las herramientas adecuadas y otras consistencias podrían convertirse en problemas. Finalmente, para mí, el más influyente de estos argumentos fue el número 2, la gestión de la memoria. He estado haciendo esto desde entonces.

@property (nonatomic, strong) id object; // Properties became my friends.

Para mis últimos proyectos, he cambiado a usar ARC, lo que me hizo dudar si crear propiedades para casi cualquier cosa sigue siendo una buena idea o tal vez un poco superflua. ARC se encarga de la memoria administrando objetos Objective-C para mí, lo que para la mayoría de los strongmiembros funciona bien si solo declaras los ivars. Los tipos C que tenía que administrar manualmente de todos modos, antes y después de ARC, y las weakpropiedades son en su mayoría públicas.

Por supuesto, todavía uso propiedades para cualquier cosa que necesite acceso desde fuera de la clase, pero en su mayoría son solo un puñado de propiedades, mientras que la mayoría de los miembros de datos se enumeran como ivars debajo del encabezado de implementación

@implementation GTWeekViewController
{
    UILongPressGestureRecognizer *_pressRecognizer;
    GTPagingGestureRecognizer *_pagingRecognizer;
    UITapGestureRecognizer *_tapRecognizer;
}

Como experimento, he estado haciendo esto un poco más rigurosamente, y el alejamiento de las propiedades de todo tiene algunos efectos secundarios positivos.

1. Los requisitos del código del miembro de datos ( @property/ @synthesize) se redujeron a solo la declaración ivar.
2. La mayoría de mis self.somethingreferencias se limpiaron solo _something.
3. Es fácil distinguir qué miembros de datos son privados (ivars) y cuáles son públicos (propiedades).
4. Por último, se siente más como si este fuera el propósito para el que Apple pretendía propiedades, pero eso es especulación subjetiva.

En cuanto a la pregunta : lentamente me estoy deslizando hacia el lado oscuro, usando cada vez menos propiedades a favor de los ivars de implementación. ¿Puede proporcionarme un poco de razonamiento de por qué debería seguir usando propiedades para todo, o confirmar mi corriente actual de pensamientos sobre por qué debería usar más ivars y menos propiedades solo donde sea necesario? La respuesta más persuasiva para cualquier lado recibirá mi marca.

EDITAR: McNally interviene en Twitter y dice : "Creo que mi razón principal para mantener las propiedades es: una forma de hacer todo, que hace todo (incluido KVC / KVO)".

¿Puede proporcionarme un poco de razonamiento de por qué debería apegarme al uso de propiedades para todo, o confirmar mi corriente actual de pensamientos sobre por qué debería usar más ivars y menos propiedades solo donde sea necesario?

En este momento, creo que es justo decir que es principalmente una cuestión de estilo. Como usted dice, el beneficio de administración de memoria de las propiedades es menos importante con ARC. Por otro lado, los "beneficios" de volver al acceso directo a ivar tampoco son muy convincentes:

1. Una declaración @property es bastante similar a una declaración ivar. Evitar la directiva @synthesize no parece una gran victoria, no estamos hablando de mucho código.

2. La foo.somethingsintaxis es posiblemente mucho mejor que _something. La sintaxis de acceso a la propiedad obviamente está diseñada para parecerse y funcionar como la sintaxis de puntos de C para acceder a los miembros de una estructura. selfEs útil ser explícito sobre a qué objeto está accediendo (ya sea eso u otra cosa). (Algunas personas, ¡no yo!) Abogan self->somethingpor el acceso a ivar por este motivo). La convención de subrayado líder para ivars está bien, pero no se usa de manera consistente en todo el código Objective-C.

3. Las propiedades parecen una mejor opción para acceder a los datos almacenados en otros objetos de la misma clase (que está permitido bajo el acceso "privado") y para el acceso por subclases (como "protegido" de C ++). Entonces la idea 'propiedades == público' es algo borrosa.

4. Mi sensación es que las propiedades estaban destinadas a simplificar la administración de la memoria y proporcionar algunos otros beneficios. Como usted dice, con el beneficio de administración de memoria disminuido, las propiedades parecen menos convincentes.

La ruta que ha elegido, volver al acceso directo a ivar para datos internos, parece una opción muy razonable y no hay una razón obvia para cambiar su curso. Pero apegarse a las propiedades también es bastante razonable: los inconvenientes no son significativos, y hay algunos beneficios agradables como el cumplimiento de KVO y un estilo de acceso de miembros más consistente.

Las propiedades no fueron el último paso en la evolución de Objective-C, y no espero que ARC lo sea tampoco. No tengo ninguna información específica, pero parece una buena suposición de que podrían agregarse características adicionales en algún momento que hagan que las propiedades sean más convincentes o menos. Tendremos que esperar y ver qué pasa.

También he estado reflexionando sobre esta pregunta. En mi humilde opinión, solo usar propiedades para los accesos hace que el código sea mucho más legible. Puede ver inmediatamente a qué variables se debe acceder públicamente. Y personalmente, siempre escribir @property (...) delante de una variable lleva mucho tiempo.