2009-06-18 25 views
22

Sono sostanzialmente la stessa cosa?Obiettivo-C. Puoi usare il protocollo come un'interfaccia Java?

Per esempio se ho un'interfaccia in Java

public interface CoolObject{ 
... 
} 

posso usare qualsiasi oggetto che implementa l'interfaccia CoolObject nelle funzioni che accettano un CoolObject come parametro:

public void foo(CoolObject o) { 
... 
} 

è questo il lo stesso in Objective-C?

@protocol CoolProtocol 
... 
@end 

@interface Foo: NSObject <CoolProtocol> 
... 
@end 

(void) - someMethod: (CoolProtocol *) obj { 
} 

Sarebbe il lavoro di cui sopra (e essere considerato corretto?)

Grazie per il vostro tempo. Fammi sapere se hai bisogno di me per chiarire la mia domanda.

risposta

34

Chiudi. In Objective C, si indica che un oggetto implementa un protocollo con parentesi angolari <>, quindi si può scrivere il tuo metodo come uno di loro:

- (void) someMethod: (id <CoolProtocol>) obj { } 
- (void) someMethod: (id <NSObject, CoolProtocol>) obj { } 
- (void) someMethod: (NSObject <CoolProtocol> *) obj { } 

In tutti i casi, stai dicendo che someMethod richiede un oggetto che implementa CoolProtocol.

id è un puntatore generico a qualsiasi tipo di oggetto Objective C.

Quindi id < CoolProtocol> significa "Qualsiasi tipo di oggetto obiettivo C che implementa CoolProtocol".

Spesso, si desidera essere in grado di mantenere/rilasciare/autorelease l'oggetto e generalmente trattarlo come un normale oggetto Cocoa, quindi è spesso consigliabile aggiungere anche il protocollo NSObject, che è ciò che il secondo caso fa .

E se si desidera assicurarsi che sia effettivamente un oggetto Cocoa corretto (esclusi gli oggetti basati su NSProxy), è possibile utilizzare l'ultimo modulo, che dice fondamentalmente "Voglio qualsiasi tipo di oggetto Cocoa Objective C che implementa CoolProtocol" .

+2

Buona risposta. Un approccio correlato è che CoolProtocol adotti il ​​protocollo NSObject, il che rende l'id funzionare perfettamente. L'ultima forma è corretta, ma in genere eccessivamente prolissa poiché gli oggetti che (involontariamente) non riescono a sottoclasse NSObject generalmente causano errori in fase di compilazione e invoca la tipizzazione statica che riduce il dinamismo che rende Objective-C così potente e flessibile. –

14

La risposta di Peters è ottima. Vorrei aggiungere una cosa però. Se si aggiunge il protocollo "NSObject" per il protocollo

@protocol CoolProtocol <NSObject> 
@end 

Ciò allevierebbe la necessità di per di dichiarare il protocollo NSObject nella dichiarazione di metodo.

- (void) someMethod: (id <NSObject, CoolProtocol>) obj { } 

Ora diventa

- (void) someMethod: (id <CoolProtocol>) obj { }