Evitar @ property-itis (es decir, uso excesivo de propiedades, ¿cuándo son apropiadas)?

Question

Objective-C 2.0 nos dio @properties.

• Permiten la introspección.
• Permiten la programación declarativa.
• Los mecanismos @synthesize y @dynamic alivian el uso de tener que escribir accesos de stock repetitivos.
• Finalmente, está la sintaxis de la propiedad 'dot', que algunos aman y otros odian.

Eso no es lo que se me ocurre preguntar. Como cualquier característica nueva, inicialmente hay una tendencia a querer usar @property en todas partes. Entonces, ¿dónde es apropiado el uso de la propiedad?

Claramente en los objetos modelo, los atributos y las relaciones son buenos forraje para las propiedades.

@property(...) NSString *firstName; 
@property(...) NSString *lastName; 
@property(...) Person *parent; 

Incluso los atributos sintetizados/calculados parecen un buen uso para las propiedades.

@property(...) NSString *fullName; 

¿Dónde más ha usado propiedades? ¿Dónde los usó, y luego decidió que era un uso inapropiado de la función?

¿Utiliza propiedades para sus atributos de objeto privado?

¿Puedes pensar en algún ejemplo de cosas que no son propiedades en Cocoa, que a primera vista parecen ser propiedades, pero después de una inspección más cercana, son un ejemplo real de abuso o propiedad?

Answer 1

Mi recomendación a las personas es utilizar la propiedad siempre que sea posible. Si está trabajando en un marco, la posibilidad de utilizar variables de instancia no frágiles en el tiempo de ejecución moderno es una gran ventaja y, si no lo está, las propiedades dejan en claro cómo deben administrarse sus ivars (asignados vs retenidos vs copiados) . No hay pérdida de rendimiento inherente al declarar una propiedad que no sea el tiempo que lleva escribir la línea de código (de hecho, utilizo un fragmento de TextExpander para hacer esto por mí), pero el potencial para evitar errores es lo suficientemente grande como para que se convierta en un fantástica mejor práctica. Si planea propiedades de usuario para ivars privadas, puede hacerlo dentro de su archivo de implementación a través de un bloque @interface. Por ejemplo

@interface MyObject() 

@property(retain) NSArray *myArray; 

@end 

Answer 2

Si tuviera que pensar en una razón para evitarlos, diría que no lo use para los atributos computados en el cálculo en cuestión es significativa. Las propiedades alientan el código como:

if (foobar.weight > 100) { 
    goober.capacity = foobar.weight; 
} 

En este ejemplo, foobar.weight se llama dos veces. Si solo devuelve un valor en caché, no hay problema. Pero si necesita bloquear el hilo mientras despliega un robot para pesar manualmente el foobar cada vez, el código cortado anteriormente desperdiciará dos implementaciones de robot cuando solo se necesita uno.

En tales casos, le recomiendo no utilizar una propiedad, y también nombrar el método diferente, por lo que el código se vería más como:

int w = [foobar computeWeight]; 
if (w > 100) { 
    goober.capacity = w; 
} 

Con un nombre como computeWeight es más fácil de recordar que es una operación de larga ejecución.

Answer 3

Evitaría usar propiedades si el método de acceso hace algo no obvio para el objeto, como establecer una variable de instancia no relacionada. Además, si la propiedad que se devuelve realmente no "pertenece" al objeto. Por ejemplo, en uno de mis proyectos tengo un método stringValue que decidí no hacer una propiedad por este motivo. Sin embargo, esto es más una cuestión de estilo.