@interface SomeClass : NSObject
@property (copy, nonatomic) NSString *usefulString;
@property (strong, nonatomic) NSString *dangerousString;
@property (copy, nonatomic) NSURL *curiousURLOne;
@property (strong, nonatomic) NSURL *curiousURLTwo;
@end
In der obigen Klasse dangerousString
ist eine schlechte Idee, weil NSMutableString
erbt von NSString
betrachtet. Das heißt, es ist möglich, dass ein Benutzer Ihrer Klasse eine veränderbare Zeichenfolge auf dangerousString
festlegen und später den Wert der veränderbaren Zeichenfolge unterhalb der Instanz SomeClass
ändern kann. Die Eigenschaft usefulString
weist diese Gefahr nicht auf, da sie den Wert in ein neues (unveränderliches) Zeichenfolgenobjekt kopiert.NSURL - Keine veränderbare Unterklasse, Sie müssen also nicht als Eigenschaft kopieren?
Es scheint jedoch wie für NSURL
(und alle anderen Foundation-Klassen, die nicht änderbare Gegenstücke haben - z. B. NSNumber
) die Kopie Semantik der Eigenschaftsdeklaration ist nicht erforderlich. NSURL
nicht zu NSCopying des konform copyWithZone:
(... aber ich muss mich fragen, ob es nur nicht das gleiche Objekt mit einem erhöhten Beibehaltungszähler zurückkehren - warum sollte es etwas anderes tun)
Warum würden Sie Eigenschaften erklären wie copy
, die keine Gefahr haben, mutiert zu werden?
Würde nicht TrickThemURL nur außer Kraft setzen -copy wenn es bösartig sein wollte? – Darren
@Darren Ich denke, du hast recht - eine Möglichkeit, sicher zu sein, ist die Verwendung von [[NSURL urlWithString: urlArg.standardizedURL] 'und validiere dann das Ergebnis. – dasblinkenlight
Basierend auf dieser Diskussion scheint "stark" "sicher" zu sein. Dies eröffnet eine Chance für ein Katz-und-Maus-Spiel, aber das kann in Ordnung sein, bis die Nützlichkeit dieser Klasse über die Grenzen einer einzelnen Anwendung hinaus wächst. – edelaney05