devono essere conformi al protocollo NSObject?

Question

Il protocollo NSObject viene fornito con i modelli di protocollo stock, ma non sembra essere tutto ciò che è necessario per le effettive implementazioni del protocollo. Lasciando perdere sembra assolutamente nulla. Quindi, è davvero necessario che un protocollo erediti da esso, o è solo un componente aggiuntivo non necessario?

Answer 1

Per anni ho (e molti come me) non ha reso i nostri protocolli conformi allo <NSObject>. Funziona bene. Ma può spesso essere fastidioso. Il disturbo più comune è che non è possibile utilizzare respondsToSelector: senza eseguire il cast back allo NSObject* (che tipo di sconfigge l'intero punto di un protocollo). Questo non importava ai giorni dell'ObjC1 perché non c'era lo @optional, quindi nessuno di noi si preoccupava (non usavamo molto i protocolli in quei giorni perché senza lo @optional non erano così utili). Quindi ObjC2 è arrivato con la meravigliosa aggiunta di metodi opzionali e all'improvviso respondsToSelector: importava. Ci è voluto un po 'di tempo per rallentarci, ma alla fine abbiamo iniziato a capire che la vita era molto più semplice se rendi i tuoi protocolli conformi allo <NSObject>. In modo intelligente questo ha fatto la sua strada in Xcode, rendendo più facile per tutti fare le cose nel modo più conveniente.

Ma no, non devi farlo. Non importa in molti casi. Ma non c'è molta ragione per non farlo, quindi lo consiglio.

Answer 2

Non necessariamente. Un delegato è solo un oggetto helper: gli unici requisiti sono quelli che la classe di delega colloca su di esso. Se si desidera formalizzare i requisiti per un determinato delegato, creare un protocollo formale, ovvero dichiarare un protocollo utilizzando la direttiva @protocol. Se conforme al protocollo NSObject è uno di quei requisiti, è possibile rendere il vostro protocollo di adottarlo:

@protocol MyDelegateProtocol <NSObject> 
//... 
@end 

Detto questo, non vedo alcuna ragione per creare un delegato che non è derivato da NSObject o forse NSProxy, e entrambe queste classi sono già conformi al protocollo NSObject.

Answer 3

Non tutti gli oggetti devono sottoclasse NSObject quindi suppongo che se si aspettasse che un tale oggetto sia conforme al protocollo, non dovrebbe necessariamente essere conforme a NSObject.

Conforme a NSObject facciamo sapere al compilatore che l'oggetto è conforme alle nozioni di base: verificarlo NSObject Protocol Reference. Senza dire che sono conforme a NSObject come fa il compilatore a sapere che sono conforme a tutto ciò?

NSObject è definito come

@interface NSObject <NSObject> { 
    Class isa; 
} 

mentre id è definito come

typedef struct objc_object { 
    Class isa; 
} *id; 

Così per id il compilatore non sa è conforme alla NSObject

Answer 4

Consiglia e non obbligatorio.

Secondo il documento ufficiale di Apple ProgrammingWithObjectiveC.pdf

Se si tenta di chiamare il metodo respondsToSelector: su un id conforme al protocollo come è definito sopra, si otterrà un errore di compilazione che non esiste un metodo di istanza noto per questo.Una volta che si qualifica un ID con un protocollo, il controllo di tipo allstatico ritorna; riceverai un errore se tenti di chiamare qualsiasi metodo che non è definito nel protocollo specificato . Un modo per evitare l'errore del compilatore è impostare il protocollo personalizzato per adottare il protocollo NSObject.

protocollo come è definito sopra è un protocollo senza conformarsi NSObject protocollo.

A titolo di esempio, è buona norma definire i protocolli di conformarsi al protocollo NSObject (alcuni dei comportamenti NSObject è divisa dal sua interfaccia classe in un protocollo separato, la classe NSObject adotta la Protocollo NSObject).