2012-12-21 3 views
9
@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?

Antwort

6

Die Tatsache, dass Apple keine veränderbare Unterklasse zur Verfügung stellt, bedeutet nicht, dass ein böswilliger Benutzer keinen speziell dafür erstellen könnte, Ihre Klasse zu betrügen. Wenn Sie unter der Annahme arbeiten, die Strings hinter Ihrer Klasse zurück geändert werden kann, müssen Sie zumindest eine Möglichkeit eines böswilligen Benutzer erlauben, NSURL in eine veränderbare Klasse erweitert:

@interface TrickThemURL : NSURL 
    // override key properties, such as baseURL and host, to be mutable 
@end 

Wenn ein Programmierer Sie gibt ein Objekt von TrickThemURL und Sie es vor der Überprüfung nicht kopieren, ist dieser Programmierer jetzt frei, die URL zu ändern, ohne Ihre Klasse wissen zu lassen.

+2

Würde nicht TrickThemURL nur außer Kraft setzen -copy wenn es bösartig sein wollte? – Darren

+0

@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

+0

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

9

Mit iOS7 Sie NSURLComponents verwenden können, jetzt ist es sehr einfach, sehen diese Beispiele:

NSString *urlString = @"https://mail.google.com/mail/u/0/?shva=1#inbox"; 
NSURLComponents *components = [[NSURLComponents alloc] initWithString:urlString]; 

NSLog(@"%@ - %@ - %@ - %@", components.scheme, components.host, components.query, components.fragment); 



NSURLComponents *components = [NSURLComponents new]; 
[components setScheme:@"https"]; 
[components setHost:@"mail.google.com"]; 
[components setQuery:@"shva=1"]; 
[components setFragment:@"inbox"]; 
[components setPath:@"/mail/u/0/"]; 

[webview loadRequest:[[NSURLRequest alloc] initWithURL:[components URL]]]; 
+0

Ich bin mir nicht sicher, was das mit der obigen Frage zu tun hat? Es sieht so aus, als ob Sie nur zeigen, wie Sie mit NSURLComponents eine URL erstellen. – codecaffeine

+0

Ja, aber die Frage war nicht zu fragen, wie man einen Teil der URL ändert, es wurde gefragt, ob es notwendig ist, eine 'NSURL'-Eigenschaft als' Kopie 'zu setzen, weil sie unveränderlich ist. – codecaffeine

Verwandte Themen