Assurer «copier» sur une déclaration de propriété va sûrement à l'encontre de l'utilisation d'un environnement orienté objet où les objets sur le tas sont passés par référence - l'un des avantages que vous obtenez ici est que, lors du changement d'un objet, toutes les références à cet objet voir les dernières modifications. De nombreuses langues fournissent des mots-clés «ref» ou similaires pour permettre aux types de valeur (c'est-à-dire les structures sur la pile) de bénéficier du même comportement. Personnellement, j'utiliserais la copie avec parcimonie, et si je pensais qu'une valeur de propriété devait être protégée des modifications apportées à l'objet à partir duquel elle était affectée, je pouvais appeler la méthode de copie de cet objet pendant l'affectation, par exemple:
p.name = [someName copy];
Bien sûr, lors de la conception de l'objet qui contient cette propriété, vous seul saurez si la conception bénéficie d'un modèle dans lequel les affectations prennent des copies - Cocoawithlove.com a ce qui suit à dire:
"Vous devez utiliser un accesseur de copie lorsque le paramètre setter peut être modifiable, mais vous ne pouvez pas faire changer l'état interne d'une propriété sans avertissement " - donc vous décidez si vous pouvez supporter la valeur à modifier de manière inattendue. Imaginez ce scénario:
//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.
Dans ce cas, sans utiliser de copie, notre objet contact prend automatiquement la nouvelle valeur; si nous l'utilisions, cependant, nous devrions nous assurer manuellement que les modifications ont été détectées et synchronisées. Dans ce cas, conserver la sémantique peut être souhaitable; dans un autre, une copie pourrait être plus appropriée.
nameêtre libérédeallocou non?