Pregunta

(Solo para dejarlo ahora, estoy aprendiendo a desarrollar para iPhone con un libro que llamé Beginning iPhone 3 Development: Explorando el SDK, y no uso el generador de interfaces) ¿Hay alguna razón para usar el captador en la misma clase, cuando un miembro privado es visible? Como en Foo.h, tener

NSObject *myObj;
...
@property (nonatomic, retain)NSObject *myObj;

y luego en Foo.m, ¿accede al miembro myObj usando self.myObj (o [self myObj])? Porque en mi libro, esto es lo que te dice que escribas en una de las aplicaciones (está comprobando si la vista de un miembro de UIViewController está en la supervista):

if(self.yellowViewController.view.superview == nil) {

(observe el self .yellowViewController ...) ¿Existe realmente una razón para esto? Si no hay una idea que tengo es quizás porque el miembro blueViewController es de la clase BlueViewController, por lo que creo que si no hay ninguna razón para no causar confusión. Entonces, ¿hay algún momento en el que sea necesario usar el captador en la misma clase?

¡Gracias!

¿Fue útil?

Solución

Sí, acceder a sus ivars a través de un getter que directamente es algo bueno.

Como ejemplo: uno de los patrones de diseño normales en Cocoa (especialmente en el teléfono, donde los recursos son muy limitados) se llama carga diferida.

En resumen, significa que no cargue un recurso hasta que lo necesite.

Idealmente, desearía colocar un código en su captador que verificaría si el recurso que se solicita está cargado y, de lo contrario, cárguelo. Acceder al ivar directamente solo devolvería nil. La alternativa sería inicializar todos los ivars cuando se inicia su clase principal, lo que potencialmente desperdicia recursos para almacenar datos que pueden o no ser necesarios.

Esto también le permite colocar recursos que podrían recuperarse nuevamente en sus métodos applicationDidReceiveMemoryWarning: y volcarlos cuando los recursos se reducen, porque se cargarán nuevamente a pedido cuando sea necesario.

Otros consejos

Getter de carga diferida:

- (UIImageView*) getImageView
{
    if (!imageView)
    {
        imageView = [[UIImageView alloc] initWithImage: [UIImage imageNamed: @"blah.png"]]; // just an example
    }
    return imageView;
}

Dependiendo de cómo se defina imageView (copiar, asignar, retener), deberá modificar la asignación real, pero esto es lo que se entiende por carga diferida.

Algunas razones para usar la sintaxis getter self.ivar en lugar de acceder directamente a la variable de instancia:

  • Propiedades de carga diferida, como otros han mencionado
  • Las subclases pueden querer anular la propiedad y hacer que la superclase respete eso
  • Si usa propiedades atómicas, la única forma correcta de acceder a la propiedad es a través del captador
Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top