In Objective-C su iOS, qual è la differenza (stile) tra "self.foo" e "foo" quando si usano getter sintetizzati?

Question

Ho cercato molte domande su accessors ObjC e accessors sintetizzati inutilmente. Questa domanda è più di una domanda "aiutami a risolvere un problema"; Non mi aspetto una risposta, ma sono piuttosto alla ricerca di esperti che valutino l'argomento.

In una classe Cocoa Touch, vorrei scrivere qualche codice come questo (dove soundEffects è una struttura NSArray sintetizzata):

id foo = [self.soundEffects objectAtIndex:1]; 

Un collega mi ha chiesto di spiegare il motivo per cui quanto sopra è meglio di questa linea:

id foo = [soundEffects objectAtIndex:1]; 

Bene, funzionalmente, non è diverso.

mie argomentazioni per l'ex sono come segue:

1. self.soundEffects dice ogni altro coder lavorare sul codice che si tratta di un iVar, non una variabile ambito locale.

2. Se fosse necessario, potremmo inserire la logica personalizzata nell'accessorio getter soundEffects.

3. Per nessun motivo concreto, "sembra" la cosa giusta da fare dopo aver lavorato in Obj-C per un anno.

accetta argomenti # 1 e # 2 come valido, ma dà anche il contrappunto:

1. Non è questo solo codice di pesantezza?

2. Non si dovrebbe consentire a una classe di parlare direttamente con i propri iVars senza dover chiamare un metodo (il getter) su se stesso?

Chi prende?

Answer 1

tuo punto 1 non è giusto: è self.soundEffectsnon un Ivar, anche se può capitare di darvi qualcosa che è - come avviene nel caso del vostro sintetizzato NSArray, al momento .

Questo a sua volta implica che il punto 2 è il nocciolo della questione: se instradi tutti gli accessi tramite l'accessor, allora tutto è ben incapsulato e sei libero di modificare l'implementazione in seguito senza dovermi preoccupare del lato effetti.

È anche una buona pratica quando si utilizza il mutatore, in modo da mantenere una gestione coerente della memoria.

Per la maggior parte, io direi che è consigliabile percorso attraverso self.property per tutto ciò che è una proprietà, e limitare l'accesso Ivar diretto alle cose che sono strettamente interno. Tuttavia, ammetto che in alcuni casi, specialmente per le cose che non usano la semantica retain/copy, può essere più una preferenza di stile.

Answer 2

utilizzando qualcosa come self.variable = nil fa passare la variabile attraverso il suo setter e quindi ottiene la memoria gestita gratuitamente. se si usa semplicemente variable = nil per esempio in un metodo dealloc, causerà una perdita poiché non sta effettivamente passando attraverso il setter sintetizzato per la variabile e diminuendo il conteggio dei ritiri. Vedi questo post memory leak with self.

Per questo motivo, è consigliabile (credo) utilizzare sempre l'auto. quando si tratta di variabili di istanza possedute per quanto riguarda la gestione della memoria.

Answer 3

Personalmente ho scelto di utilizzare un prefisso di sottolineatura per Ivars, e questo tipo di sintetizzare

@synthesize name = _name; 

In questo modo non li mischiare.Il problema principale con non utilizzando sé è che questo codice

_name = ... 

è molto diverso da

self.name = ... 

Quando il @property utilizza l'opzione conservare. Il primo non mantiene l'oggetto e il secondo chiama il setter sintetizzato che conserva.

L'unica volta che fa una grande differenza è con l'assegnazione, quindi tendo a usare sempre self. quindi mi assicuro di farlo sugli assegnamenti.

Answer 4

self.soundEffects

imposta/ottiene la variabile di istanza tramite il setter/getter, e quindi se vogliamo fare alcune operazioni personalizzate quando il loro valore cambia, quella logica può andare nel loro getter/setter.

anche come per iOS 6, l'ivar corrispondente a

@property (nonatomic)NSArray *propertyName;

sarà

_propertyName

quindi credo che non puoi utilizzare

id foo = [soundEffects objectAtIndex:1];

anymore.Not sicuro though.Instead si dovrebbe usare

id foo = soundEffects[1];