¿Debo usar palabras clave propias (propiedades) en la implementación?

Question

Creo que entiendo las propiedades en su mayor parte. Mi pregunta es, si tengo una propiedad para una variable de instancia, y estoy estableciendo o recuperando desde un método en mi archivo de implementación, ¿debo usar self.myProperty o solo myProperty? Sé que cualquiera de las dos funciona, pero he visto convenciones mixtas, a veces el código accede directamente a la variable y otras veces a través de la propiedad.

¿Hay alguna razón técnica para hacer esto? ¿Es solo convención/preferencia personal? Y no me refiero a las instancias donde el nombre del parámetro de un método colisiona con el nombre de la variable de instancia, que podría ser una de las razones para usar la propiedad (Al menos, en otros idiomas, no sé de este) Asumo que cuando se utiliza la propiedad dentro de la aplicación, que quieren tomar ventaja de la forma en la que manifestaron la propiedad (es decir, no atómica, retener), así que por ejemplo en un método, se puede hacer:

self.myProperty = [someObject someAutoReleasedObject]; 

en lugar de:

myProperty = [[someObject someAutoReleasedObject] retain]; 

Es esta la razón? Entonces, ¿hay solo ciertas situaciones en las que sería bueno usar la propiedad?

Soy nuevo en Objective-C, y esta es una de las pocas cosas que me tiene confundido. Hasta ahora acabo de acceder a la variable de instancia directamente, bajo la suposición falsa más probable de que al pasar por la propiedad en realidad se llama/envía un método/mensaje y se agrega una sobrecarga innecesaria. Estoy bastante seguro de que estoy equivocado con esto, pero incluso si la diferencia en la sobrecarga es insignificante (si es que hay alguna), ¿por qué elegir agregarla cuando uno simplemente puede acceder directamente a la variable?

Estoy bastante seguro de que estoy equivocado en mi forma de pensar, por lo que estoy preguntando aquí.

Answer 1

En primer lugar, no debe utilizar setters o getters en init o dealloc según la documentación de Apple (y por buenas razones).

Aparte de eso, generalmente debe usar el colocador para establecer la variable, si es que hay una.

Normalmente no me molesto en usar el getter para acceder al ivar desde dentro de la implementación, pero a veces es necesario. En particular, si espera que el getter pueda realizar alguna conversión o comprobación, o si desea permitir subclases para anular el comportamiento.

Ciertamente, usar el getter en la implementación es más general y más seguro, pero también es inútil y desperdiciado. Haga su elección.

Usar el setter es importante ya que le da la oportunidad a otros códigos de observar los cambios (Key Value Observation), así como las subclases la posibilidad de anular el setter y hacer cualquier otro ajuste requerido.

Sin embargo, una cosa que recomiendo es usar un nombre diferente para su ivar y su propiedad. La convención normal es un prefijo de subrayado (_), aunque personalmente uso i_ como prefijo para evitar cualquier confusión con el uso privado de Apple. De esa manera no se puede utilizar accidentalmente el equivocado:

self.name // use property 
i_name // use ivar 
self.i_name // syntax error 
name // syntax error 

Answer 2

Si expone la propiedad al mundo exterior y la está utilizando internamente, debe utilizar la propiedad en todo su código. La razón es encapsulación. Supongamos que tiene una propiedad "Id" para SomeObj. Digamos que en algún momento decides reemplazar la forma en que se comporta Id (tal vez comenzaste con Id siendo un miembro var de la clase, y mediante la evolución se convierte en una pieza de datos que se recupera de la base de datos). Ahora tiene que pasar por la implementación de su clase y reemplazar todas las referencias a la var miembro con las llamadas a la base de datos. Si tuviera self.Id, solo tendría que anular el getter.