Proprietà NSString: copia o conserva?

Diciamo che ho una classe chiamata SomeClasscon un stringnome di proprietà:

@interface SomeClass : NSObject
{
    NSString* name;
}

@property (nonatomic, retain) NSString* name;

@end

Comprendo che il nome potrebbe essere assegnato a NSMutableStringnel qual caso ciò potrebbe portare a comportamenti errati.

• Per le stringhe in generale, è sempre una buona idea utilizzare l' copyattributo anziché retain?
• Una proprietà "copiata" è in qualche modo meno efficiente di una proprietà "mantenuta"?

Per gli attributi il ​​cui tipo è una classe di valori immutabili conforme al NSCopyingprotocollo, è necessario specificare quasi sempre copynella propria @propertydichiarazione. Specificare retainè qualcosa che non vorrai quasi mai in una situazione del genere.

Ecco perché vuoi farlo:

NSMutableString *someName = [NSMutableString stringWithString:@"Chris"];

Person *p = [[[Person alloc] init] autorelease];
p.name = someName;

[someName setString:@"Debajit"];

Il valore corrente della Person.nameproprietà sarà diverso a seconda che la proprietà sia dichiarata retaino copy- lo sarà @"Debajit"se la proprietà è contrassegnata retain, ma @"Chris"se la proprietà è contrassegnata copy.

Poiché in quasi tutti i casi si desidera impedire la mutazione degli attributi di un oggetto dietro la sua schiena, è necessario contrassegnare le proprietà che li rappresentano copy. (E se scrivi tu stesso il setter invece di usarlo @synthesize, dovresti ricordarti di usarlo copyinvece che retainin esso.)

Copia dovrebbe essere usato per NSString. Se è mutabile, viene copiato. In caso contrario, viene semplicemente trattenuto. Esattamente la semantica che desideri in un'app (lascia che il tipo faccia il meglio).

Per le stringhe in generale, è sempre una buona idea utilizzare l'attributo copia invece di conservare?

Sì - in generale usa sempre l'attributo copy.

Questo perché alla tua proprietà NSString può essere passata un'istanza NSString o un'istanza NSMutableString , e quindi non possiamo davvero determinare se il valore che viene passato è un oggetto immutabile o mutabile.

Una proprietà "copiata" è in qualche modo meno efficiente di una proprietà "mantenuta"?

• Se la tua proprietà viene passata a un'istanza NSString , la risposta è " No " - la copia non è meno efficiente del mantenimento.
  (Non è meno efficiente perché NSString è abbastanza intelligente da non eseguire effettivamente una copia.)

• Se alla tua proprietà viene passata un'istanza NSMutableString, la risposta è " Sì " - la copia è meno efficiente della conservazione.
  (È meno efficiente perché devono verificarsi un'allocazione e una copia effettive della memoria, ma questa è probabilmente una cosa desiderabile.)

• In generale, una proprietà "copiata" ha il potenziale per essere meno efficiente, tuttavia attraverso l'uso del NSCopyingprotocollo è possibile implementare una classe "altrettanto efficiente" da copiare come da conservare. Le istanze di NSString ne sono un esempio.

Generalmente (non solo per NSString), quando dovrei usare "copia" invece di "trattenere"?

Dovresti sempre usarlo copyquando non vuoi che lo stato interno della proprietà cambi senza preavviso. Anche per oggetti immutabili, gli oggetti immutabili scritti correttamente gestiranno la copia in modo efficiente (vedere la sezione successiva relativa all'immutabilità e NSCopying).

Potrebbero esserci motivi di prestazioni per gli retainoggetti, ma viene fornito con un overhead di manutenzione: è necessario gestire la possibilità che lo stato interno cambi al di fuori del codice. Come si suol dire, ottimizzare per ultimo.

Ma ho scritto che la mia classe è immutabile, non posso semplicemente "conservarla"?

No - usa copy. Se la tua classe è davvero immutabile, è consigliabile implementare il NSCopyingprotocollo per fare in modo che la tua classe si restituisca quando copyviene usata. Se lo fai:

• Altri utenti della tua classe otterranno i vantaggi in termini di prestazioni quando lo usano copy.
• L' copyannotazione rende il tuo codice più gestibile: l' copyannotazione indica che non devi preoccuparti che questo oggetto cambi stato altrove.

Provo a seguire questa semplice regola:

• Voglio mantenere il valore dell'oggetto nel momento in cui lo sto assegnando alla mia proprietà? Usa copia .

• Voglio aggrapparmi all'oggetto e non mi interessa quali sono i suoi valori interni attualmente o che saranno in futuro? Usa forte (mantieni).

Per illustrare: voglio mantenere il nome "Lisa Miller" ( copia ) o voglio mantenere la persona Lisa Miller ( forte )? Il suo nome potrebbe in seguito cambiare in "Lisa Smith", ma sarà sempre la stessa persona.

Attraverso questo esempio copia e conserva possono essere spiegati come:

NSMutableString *someName = [NSMutableString stringWithString:@"Chris"];

Person *p = [[[Person alloc] init] autorelease];
p.name = someName;

[someName setString:@"Debajit"];

se la proprietà è di tipo copia,

verrà creata una nuova copia per la [Person name]stringa che conterrà il contenuto della someNamestringa. Ora qualsiasi operazione su someNamestringa non avrà alcun effetto su [Person name].

[Person name]e le someNamestringhe avranno indirizzi di memoria diversi.

Ma in caso di ritenzione,

entrambi [Person name]manterranno lo stesso indirizzo di memoria della stringa di somename, solo il conteggio della stringa di somename verrà incrementato di 1.

Quindi qualsiasi cambiamento nella stringa di somename si rifletterà nella [Person name]stringa.

Sicuramente mettere 'copia' su una dichiarazione di proprietà vola di fronte all'uso di un ambiente orientato agli oggetti in cui gli oggetti sull'heap vengono passati per riferimento - uno dei vantaggi che ottieni qui è che, quando si modifica un oggetto, tutti i riferimenti a quell'oggetto vedere le ultime modifiche. Molte lingue forniscono "ref" o parole chiave simili per consentire ai tipi di valore (ovvero strutture in pila) di beneficiare dello stesso comportamento. Personalmente, userei la copia con parsimonia, e se sentissi che un valore di proprietà dovrebbe essere protetto dalle modifiche apportate all'oggetto da cui è stato assegnato, potrei chiamare il metodo di copia di quell'oggetto durante l'assegnazione, ad esempio:

p.name = [someName copy];

Naturalmente, quando si progetta l'oggetto che contiene quella proprietà, solo tu saprai se il design beneficia di uno schema in cui le assegnazioni prendono copie - Cocoawithlove.com ha il seguente da dire:

"Dovresti usare un accessore di copia quando il parametro setter può essere mutabile ma non puoi avere lo stato interno di una proprietà che cambia senza preavviso " - quindi il giudizio sul fatto che puoi sopportare il valore da modificare inaspettatamente è tutto tuo. Immagina questo scenario:

//person object has details of an individual you're assigning to a contact list.

Contact *contact = [[[Contact alloc] init] autorelease];
contact.name = person.name;

//person changes name
[[person name] setString:@"new name"];
//now both person.name and contact.name are in sync.

In questo caso, senza usare la copia, il nostro oggetto contatto prende automaticamente il nuovo valore; se lo avessimo usato, tuttavia, avremmo dovuto assicurarci manualmente che le modifiche fossero rilevate e sincronizzate. In questo caso, mantenere la semantica potrebbe essere desiderabile; in un altro, la copia potrebbe essere più appropriata.

@interface TTItem : NSObject    
@property (nonatomic, copy) NSString *name;
@end

{
    TTItem *item = [[TTItem alloc] init];    
    NSString *test1 = [NSString stringWithFormat:@"%d / %@", 1, @"Go go go"];  
    item.name = test1;  
    NSLog(@"-item.name: point = %p, content = %@; test1 = %p", item.name, item.name, test1);  
    test1 = [NSString stringWithFormat:@"%d / %@", 2, @"Back back back"];  
    NSLog(@"+item.name: point = %p, content = %@, test1 = %p", item.name, item.name, test1);
}

Log:  
    -item.name: point = 0x9a805a0, content = 1 / Go go go; test1 = 0x9a805a0  
    +item.name: point = 0x9a805a0, content = 1 / Go go go, test1 = 0x9a84660

Utilizzare sempre copia per dichiarare la proprietà NSString

@property (nonatomic, copy) NSString* name;

Dovresti leggere queste informazioni per ulteriori informazioni sul fatto che restituisca una stringa immutabile (nel caso in cui sia stata passata una stringa mutabile) o restituisca una stringa mantenuta (nel caso in cui fosse passata una stringa immutabile)

Riferimento al protocollo NSCopying

Implementa NSCopying conservando l'originale anziché crearne una nuova quando la classe e il suo contenuto sono immutabili

Oggetti valore

Quindi, per la nostra versione immutabile, possiamo semplicemente fare questo:

- (id)copyWithZone:(NSZone *)zone
{
    return self;
}

Poiché name è un (immutabile) NSString, copiare o conservare non fa alcuna differenza se ne imposti un altro NSString. In altre parole, la copia si comporta esattamente come conserva, aumentando il conteggio dei riferimenti di uno. Penso che sia un'ottimizzazione automatica per le classi immutabili, poiché sono immutabili e non hanno bisogno di essere clonate. Ma quando a NSMutalbeString mstrviene impostato il nome, il contenuto di mstrverrà copiato per motivi di correttezza.

Se la stringa è molto grande, la copia influirà sulle prestazioni e due copie della stringa grande utilizzeranno più memoria.