NSString property copy or readonly?

Question

Veo muchas discusiones que dicen que debo usar copia para la propiedad NSString porque evitará que otros la cambien a mis espaldas. Pero entonces, ¿por qué no nos limitamos a configurar solo propiedad para ello?

actualización

Gracias por contestar a mi pregunta. Pero la cosa es que para la propiedad NSString, siempre no quieres que otros lo modifiquen, ¿verdad? Puede modificarlo usted mismo pero definitivamente no otros. Supongo que la mayoría de las veces NSString obtiene su valor inicial configurado (ya sea por usted o por otros), después de eso solo usted lo modificará. Entonces, ¿por qué no utilizar solo la propiedad de solo lectura

Actualmente, utilizo la copia la mayor parte del tiempo. Pero luego me doy cuenta de que la mayoría de las veces solo uso esos setters en mi método init. Así que creo que debería usar readonly en lugar de copiar para esos casos.

Así que déjame preguntarte de esta manera: si solo usas esos setters para tus NSStrings en tu método init, entonces deberías usar readonly en su lugar. ¿Es esta una conclusión razonable?

Answer 1

si solo usa esos ajustadores para sus NSStrings en su método init, entonces debería usar readonly en su lugar. ¿Es esta una conclusión razonable?

Puesto que usted no debe usar métodos de acceso en estados parcialmente construidos (init/dealloc), entonces usted debe declarar como copy y readonly, a continuación, realizar la copia en el inicializador:

- (id)initWithName:(NSString *)inName 
{ 
    self = [super init]; 
    if (0 != self) { 
    name = [inName copy]; 
    } 
    return self; 
} 

De manera más detallada , copy y readonly son conceptos semánticamente diferentes.

• Se utilizan copy porque usted está interesado en el valor en la mayoría de los casos. También es una salvaguarda y una optimización para usar cadenas inmutables.

• Utiliza readonly para prohibir a los clientes mutar/configurar sus datos.

en conjunto, proporcionan un buen nivel de seguridad, pero por sí sola:

• copy todavía permite a los clientes para ajustar el valor en cualquier punto de la ejecución del programa a través de la incubadora.

• readonly no implica copy, y una propiedad retenida podría cambiarse detrás de su espalda; considere lo que sucede cuando se pasa una variante mutable y el cliente la muta después de llamar al colocador.

La forma más segura es utilizar copy y readonly.

• , obviamente, va a utilizar readwrite cuando se necesita para proporcionar una incubadora a sus clientes, y el apoyo que ese cambio.

• conservar una cadena (o matriz, o ...) en lugar de copiar suele ser una mala idea. Rara vez es un buen uso para usted no copiar estos tipos, y puede conducir a errores sutiles. incluso cuando se trata de un tipo mutable, normalmente querrá una copia mutable (que el compilador no sintetizará para usted). retener o asignar estos tipos casi nunca es lo que desea. Una excepción que hago es cuando se trata de grandes asignaciones, donde los datos se encapsulan bien (por ejemplo, una instancia pesada de NSMutableData que paso la propiedad de un lugar a otro para evitar una copia).

Answer 2

Si no desea que otros modifiquen su propiedad, debe marcarlo readonly. Lo que las personas quieren decir cuando dicen usar copy significa que la cadena no se puede cambiar detrás de su espalda, si alguien asigna una cadena a su propiedad, y la cadena es mutable, y luego mutan la cadena, cuando más tarde acceda a su propiedad Volveremos al cambiado cadena. Pero si usa copy, obtendrá una instantánea de cómo se veía la cadena en el momento en que se asignó a la propiedad (que es lo que la gente espera que suceda).

Answer 3

Puede hacer ambas cosas. Como NSString es inmutable, la cadena subyacente no se puede cambiar. Sin embargo, es posible que no desee que cambie la referencia, por lo que lo utiliza de forma sencilla.

La copia solo se aplica al colocador, el captador aún devolverá una referencia, no una copia.