type sécurité paramètre méthode Objective-C

Question

Si j'ai des méthodes telles que:

- (BOOL)isValidRow:(NSDictionary*)contentVersionRow 

avons-nous vraiment vérifier en permanence comme celui-ci au début de la méthode

if(![contentVersionRow isKindOfClass:[NSDictionary class]]) { 
    // Handle unusual situation - probably return NO in this case 
} 

à mettre en œuvre vraiment bon type-sécurité à l'intérieur des méthodes Objective-C? Parce qu'en théorie le paramètre n'est pas garanti pour pointer vers un objet NSDictionary, est-ce correct?

EDIT: Donc, les réponses semblent indiquer que nous ne devrions pas vérifier cela, mais alors quelle est la différence entre vérifier cela et vérifier le paramètre nil, ce que je suppose que nous devrions faire? Ou ne devrions-nous pas vérifier non plus, si ce n'est normalement pas prévu? Les deux cas couvrent la situation d'un appelant mal se comporter.

Answer 1

Tout comme dans C vous avez affaire à des pointeurs en Objective-C. Donc dire NSDictionary * signifie simplement "voici un pointeur vers une adresse mémoire qui contient une instance de NSDictionary".

Exemple:

#import <Foundation/Foundation.h> 

@interface Test : NSObject 
- (void)useDictionary:(NSDictionary *)dictionary; 
@end 

@implementation Test 
- (void)useDictionary:(NSDictionary *)dictionary 
{ 
    NSLog(@"Keys: %@", [dictionary allKeys]); 
} 
@end 

int main(int argc, char *argv[]) { 
    @autoreleasepool { 
     Test *test = [[Test alloc] init]; 

     // 1: This works fine 
     [test useDictionary:@{@"key": @"value"}]; 

     // 2: This will cause a compiler warning (or error depending on the options passed to the compiler) 
     [test useDictionary:@"not a dictionary"]; 

     // 3: This will compile without any warnings 
     [test useDictionary:(NSDictionary *)@"not a dictionary"]; 
    } 
} 

Les 2e et 3e exemples provoqueront un plantage du programme lors de l'exécution. Donc, si vous voulez transmettre des choses incorrectes à des méthodes, vous pouvez le faire. Habituellement, Xcode vous avertira si vous avez une incompatibilité de type.

Mise à jour à propos de la vérification nil: Si c'est une mauvaise utilisation de l'API pour passer nil à votre méthode, alors lancez une exception. C'est ce que les exceptions sont dans Objective-C: pour attraper programmation erreurs, de ne pas gérer les problèmes d'exécution attendus (comme un réseau inaccessible). Si votre méthode peut simplement échouer silencieusement si nil est passé ou la gérer de manière sensée, faites-le à la place. Par exemple si vous avez une méthode addValue:(NSNumber *)number qui ajoute la valeur donnée à une somme alors ce ne serait pas un gros problème si quelqu'un l'appelait avec nil: N'ajoutez rien du tout :)

Answer 2

Oui, mais vous ne devriez pas. Obj-C est un langage dynamique, il appartient donc à chaque objet de déterminer s'il répond à une méthode donnée. C'est un mauvais style de vérifier la classe d'un objet. Au lieu de cela, si vous voulez vérifier qu'un objet supporte un sélecteur, vous devez utiliser -respondsToSelector:, mais seulement si vous gérez des objets qui ne répondent pas à ce sélecteur.