Usando una propiedad BOOL


111

Apple recomienda declarar una propiedad BOOL de esta manera:

@property (nonatomic, assign, getter=isWorking) BOOL working;

Como estoy usando las propiedades de Objective-C 2.0 y la notación de puntos, accedo a esta propiedad usando self.working . Sé que yo también podría usar[self isWorking] , pero no es necesario.

Entonces, como estoy usando la notación de puntos en todas partes, ¿por qué debería definir una propiedad adicional? ¿Estaría bien simplemente escribir

@property (nonatomic, assign) BOOL working;

¿O tengo algún beneficio escribiendo getter=isWorking en mi caso (uso de notación de puntos)?

¡Gracias!


4
¿No es esta una recomendación basada en la semántica? por lo que myCar.isWorking sería semánticamente más preciso que myCar.working
compila

Respuestas:


206

Apple simplemente recomienda declarar un isXcaptador por motivos de estilo. No importa si personaliza el nombre del captador o no, siempre que utilice la notación de puntos o la notación de mensaje con el nombre correcto. Si va a usar la notación de puntos, no hay diferencia, aún puede acceder a ella por el nombre de la propiedad:

@property (nonatomic, assign) BOOL working;

[self setWorking:YES];         // Or self.working = YES;
BOOL working = [self working]; // Or = self.working;

O

@property (nonatomic, assign, getter=isWorking) BOOL working;

[self setWorking:YES];           // Or self.working = YES;, same as above
BOOL working = [self isWorking]; // Or = self.working;, also same as above

4
¿Seguramente tiene más que ver con cumplir con la codificación de valores clave que solo con fines estilísticos?
Jasarien

5
Es un poco extraño que Apple recomiende declarar esos isXcaptadores, pero Xcode no puede enumerarlos en la ventana emergente de finalización automática. (En mi ejemplo) workingaparece allí, pero isWorkingno lo está. Así que no veo ningún beneficio en declarar captadores BOOL. Tengo que hacer más para poder usarlos (declarar el getter) pero obtengo menos (sin autocompletar).
Patrick

4

Apple recomienda con fines estilísticos. Si escribe este código:

@property (nonatomic,assign) BOOL working;

Entonces no puede usar [object isWorking].
Mostrará un error. Pero si usa el siguiente código significa

@property (assign,getter=isWorking) BOOL working;

Entonces puede usar [object isWorking].


-26

No hay ningún beneficio al usar propiedades con tipos primitivos. @propertyse utiliza con el montón asignado NSObjectscomo NSString*, NSNumber*, UIButton*, y etc, porque descriptores de acceso de memoria administrada se crean de forma gratuita. Cuando crea un BOOL, el valor siempre se asigna en la pila y no requiere ningún acceso especial para evitar pérdidas de memoria. isWorkinges simplemente la forma popular de expresar el estado de un valor booleano.

En otro lenguaje OO, haría una variable private bool working;y dos accesos: SetWorkingpara el definidor y IsWorkingpara el accesor.


1
No está respondiendo a su pregunta, es decir, cuál es el propósito de nombrar explícitamente al getter algo más que la propiedad (no está preguntando si las propiedades son una buena idea). Además, las propiedades permiten KVO y KVC, por lo que el punto que hace es engañoso.
Martin Gjaldbaek

Tienes razón en que pasé por alto el uso de KVO y KVC con propiedades primitivas. Creo que todos en el hilo están abordando su pregunta sobre isWorking, es una convención de nomenclatura.
Thomson Comer

25
Esto es completamente incorrecto; @propertyestá destinado a ser utilizado con tipos primitivos y, solo por motivos de coherencia, tiene ventajas significativas. Además, algunos tipos primitivos (tipos de 64 bits en algunas CPU de 32 bits y tipos de 128 bits en muchas CPU de 32 y 64 bits) no son atómicos en la asignación; @propertyLa atomicidad también puede ser ventajosa en esos casos.
bbum

1
Interesante, pero ¿cómo diablos se supone que voy a saber eso? :) ¿Es esto una implicación de los atributos atomicy nonatomic?
Thomson Comer
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.