¿Hay alguna razón para declarar ivars si está utilizando propiedades exclusivamente en Objective-C?

Question

Tiendo a utilizar propiedades exclusivamente en mis clases, especialmente ahora que puede declarar propiedades en una extensión de clase gracias al moderno tiempo de ejecución de Objective-C 2.0: uso esta característica para crear propiedades "privadas".

Mi pregunta es si ya existe alguna buena razón para declarar ivars en una interfaz de clase. Prefiero que mis interfaces públicas sean lo más mínimas y limpias posible, solo revelando aspectos de mi clase que sean pertinentes.

Por ejemplo, yo tendería a hacer lo siguiente:

MyClass.h:

@interface MyClass : NSObject 

@property (nonatomic, copy) NSString * publicString; 
@property (nonatomic, copy, readonly) NSString * readOnlyString; 

@end 

MyClass.m:

@interface MyClass() 

@property (nonatomic, copy, readwrite) NSString * readOnlyString; 
@property (nonatomic, copy) NSString * privateString; 

@end 

@implementation MyClass 

@synthesize publicString = publicString_; 
@synthesize readOnlyString = readOnlyString_; 
@synthesize privateString = privateString_; 

- (void)init 
{ 
    self = [super init]; 

    if (self != nil) 
    { 
     self.publicString = @"Public String"; 
     self.readOnlyString = @"Read-Only String"; 
     self.privateString = @"Private String"; 
    } 

    return self; 
} 

- (void)dealloc 
{ 
    [publicString_ release]; 
    [readOnlyString_ release]; 
    [privateString_ release]; 

    [super dealloc]; 
} 

@end 

preferencias de estilo de código a un lado, ¿hay algún problema con evitando Ivars enteramente ¿Me gusta esto?

Answer 1

Puede haber encontrado una respuesta que sea lo suficientemente adecuada para que respalde explícitamente mis propiedades con ivars. No parece que el depurador enumerará todos los ivars sintetizados automáticamente, por lo que no hay forma de simplemente navegar a través de self durante la depuración y comprobar varios valores que no sean llamar manualmente a los accesores de propiedad, lo que es tedioso. A menos que cambien esto, esta es probablemente una razón más que suficiente para que yo simplemente regrese a declarar ivars explícitamente.

Answer 2

El problema principal, si le molesta, es que por Cocoa With Love, variables de instancia dinámicas como las que está utilizando no son compatibles con tiempos de ejecución distintos a los de 64 bits Intel/PowerPC (corregidos por comentario de Chuck a continuación) y ARM (para iOS).

Actualmente no puedo encontrar un documento autorizado de Apple sobre el tema; tenga en cuenta que restringir a la última versión de OS X, v10.6, no es suficiente, ya que está disponible y es compatible con las máquinas Intel de 32 bits que Apple envió inmediatamente después de cambiar de PowerPC.

Pensamiento extra tardío: sin tener conocimiento de posibles cambios en Xcode 4, una buena razón para declarar variables de instancia privadas dentro del archivo de encabezado es marcarlos como IBOutlets y conectarlos gráficamente. Sin embargo, eso solo es relevante para un tipo muy específico de clase y variable miembro.

Answer 3

Más allá de la preocupación de Tommy, declarar un ivar es ciertamente una buena práctica, especialmente si su código puede ser reutilizado o si alguna vez puede volver a su código.

Answer 4

Tengo que estar de acuerdo con LucasTizma en el tema de la depuración.

Cuando comencé a usar XCode4, comencé a no declarar explícitamente ivars y dejar que se crearan para mí usando @synthesize aVar = _aVar sintaxis. Al intentar depurar el código, noté que no podía pasar el cursor sobre la variable y ver su valor.

Para mí, esto es simplemente inaceptable. Supongo que es volver a declararlos explícitamente.