Signature de méthode pour un sélecteur

Question

Je suis novice dans le domaine de l'Objective C (développeur Java la plupart du temps) et je suis en train de me lancer dans ma première application de tueur. :-) Pour l'instant, je suis un peu confus à propos de l'utilisation des sélecteurs comme arguments de méthode. Ils semblent être un peu différents des délégués en C# par exemple.

Compte tenu de la signature de la méthode suivante

-(void)execute:(SEL)callback; 

est-il un moyen de faire respecter la signature du sélecteur est passé à une telle méthode? La méthode attend un sélecteur d'une méthode avec la signature suivante

-(void)foo:(NSData*)data; 

Mais le SEL (type) est générique, donc il y a une bonne chance de passer un mauvais sélecteur sur la méthode exécuter. OK au moins au moment de l'exécution on verrait un comportement amusant ... mais je voudrais voir un avertissement/erreur du compilateur lorsque cela se produit.

Answer 1

La réponse rapide est: non, il n'y a pas moyen d'avoir le compilateur appliquer la signature de la méthode d'un sélecteur de méthode qui est fournie par un argument SEL. L'un des points forts d'Objective-C est qu'il s'agit d'un langage faiblement typé, qui permet un comportement beaucoup plus dynamique. Bien sûr, cela se fait au détriment de la sécurité de type à la compilation. Afin de faire ce que (je pense) que vous voulez, la meilleure approche est d'utiliser des délégués. Cocoa utilise des délégués pour permettre à une autre classe d'implémenter des méthodes de type "callback". Voici comment il pourrait ressembler:

FooController.h

@protocol FooControllerDelegate 
@required: 
- (void)handleData:(NSData *)data forFoo:(FooController *)foo; 
@end 

@interface FooController : NSObject 
{ 
    id <FooControllerDelegate> * delegate; 
} 
@property (assign) id <FooControllerDelegate> * delegate; 
- (void)doStuff; 
@end 

FooController.m

@interface FooController (delegateCalls) 
- (void)handleData:(NSData *)data; 
@end 

@implementation FooController 

@synthesize delegate; 

- (id)init 
{ 
    if ((self = [super init]) == nil) { return nil; } 
    delegate = nil; 
    ... 
    return self; 
} 

- (void)doStuff 
{ 
    ... 
    [self handleData:data]; 
} 

- (void)handleData:(NSData *)data 
{ 
    if (delegate != nil) 
    { 
     [delegate handleData:data forFoo:self]; 
    } 
    else 
    { 
     return; 
     // or throw an error 
     // or handle it yourself 
    } 
} 

@end 

Utilisation du @required mot-clé dans votre protocole de délégué vous empêchera d'affecter un délégué à un FooController qui n'implémente pas la méthode exactement comme décrit dans le protocole. Tenter de fournir un délégué qui ne correspond pas à la méthode de protocole @required entraînera une erreur de compilation.

Voici comment vous créer une classe de délégué pour travailler avec le code ci-dessus:

@interface MyFooHandler <FooControllerDelegate> : NSObject 
{ 
} 
- (void)handleData:(NSData *)data forFoo:(FooController *)foo; 
@end 

@implementation MyFooHandler 
- (void)handleData:(NSData *)data forFoo:(FooController *)foo 
{ 
    // do something here 
} 
@end 

Et voici comment vous utiliseriez tout:

FooController * foo = [[FooController alloc] init]; 
MyFooHandler * fooHandler = [[MyFooHandler alloc] init]; 
... 
[foo setDelegate:fooHandler]; // this would cause a compiler error if fooHandler 
           // did not implement the protocol properly 
... 
[foo doStuff]; // this will call the delegate method on fooHandler 
... 
[fooHandler release]; 
[foo release]; 

Answer 2

Si vous souhaitez appliquer le traitement des données, utilisez isKindOfClass dans votre sélecteur. Cela fonctionne beaucoup comme instanceof que vous connaissez en Java.

Answer 3

Pour répondre directement à votre question, non, le type SEL permet tout type de sélecteur, pas seulement ceux avec une signature spécifique.

Vous pouvez envisager le passage d'un objet au lieu d'un SEL, et le document que l'objet passé doit répondre à un message particulier. Par exemple:

- (void)execute:(id)object 
{ 
    // Do the execute stuff, then... 
    if ([object respondsToSelector:@selector(notifyOnExecute:)]) { 
     [object notifyOnExecute:self]; 
    } 
    // You could handle the "else" case here, if desired 
}