ios - framework - ¿Deben los protocolos cumplir con el protocolo NSObject?

swift ios documentation

Question

El protocolo NSObject viene con las plantillas de protocolo de valores, pero no parece ser tan necesario para las implementaciones reales del protocolo. Dejarlo fuera parece no cambiar absolutamente nada. Entonces, ¿es realmente necesario que un protocolo se herede de él o es simplemente un complemento innecesario?

Answer 1

No necesariamente. Un delegado es solo un objeto auxiliar, los únicos requisitos son aquellos que la clase delegante coloca en él. Si desea formalizar los requisitos para un delegado determinado, cree un protocolo formal, es decir, declare un protocolo utilizando la directiva @protocol . Si cumplir con el protocolo NSObject es uno de esos requisitos, puede hacer que su protocolo lo adopte:

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

Dicho esto, no veo ninguna razón para crear un delegado que no se derive de NSObject o quizás NSProxy, y ambas clases ya cumplen con el protocolo NSObject.

Answer 2

No todos los objetos tienen que subclasificar NSObject por lo que supongo que si estuviera esperando que un objeto de este tipo se ajustara a su protocolo, no necesariamente tendría que cumplir con NSObject.

Conforme a NSObject, el compilador debe saber que el objeto se ajusta a los conceptos básicos: consulte NSObject Protocol Reference . Sin decir que me conformo con NSObject, ¿cómo sabe el compilador que me conformo con todo esto?

NSObject se define como

@interface NSObject <NSObject> {
Class isa;
}

mientras que id se define como

typedef struct objc_object {
Class isa;
} *id;

Así que para id el compilador no sabe que cumple con NSObject

Answer 3

Recomendable y no obligatorio.

De acuerdo con el documento oficial de Apple ProgrammingWithObjectiveC.pdf

Si intenta llamar al método respondsToSelector: en un ID que se ajuste al protocolo como se definió anteriormente, obtendrá un error del compilador que indica que no hay un método de instancia conocido para él. Una vez que califica una identificación con un protocolo, vuelve la comprobación de tipos allstatic; obtendrá un error si intenta llamar a cualquier método que no esté definido en el protocolo especificado. Una forma de evitar el error del compilador es configurar el protocolo personalizado para que adopte el protocolo NSObject.

El protocolo tal como se definió anteriormente es un protocolo sin conformar el protocolo NSObject .

Como ejemplo, es una buena práctica definir sus protocolos para que se ajusten al protocolo NSObject (parte del comportamiento de NSObject se divide de su interfaz de clase en un protocolo separado; la clase NSObject adopta el protocolo NSObject).

Answer 4

Durante años, yo (y muchos como yo) no <NSObject> nuestros protocolos a <NSObject> . Funciona bien. Pero a menudo puede ser molesto. La molestia más común es que no se puede usar respondsToSelector: sin volver a NSObject* a NSObject* (que tipo de derrota al punto entero de un protocolo). Eso no importaba en los días de ObjC1 porque no había @optional , por lo que ninguno de nosotros nos preocupaba (no @optional protocolos en absoluto en esos días, ya que sin @optional no eran tan útiles). Luego, ObjC2 vino junto con la maravillosa adición de métodos opcionales y de repente respondsToSelector: Selector respondsToSelector: importó. Tomó un poco de tiempo para los más lentos, pero al final comenzamos a descubrir que la vida era mucho más sencilla si los protocolos se ajustaban a <NSObject> . Afortunadamente, esto ahora se ha introducido en Xcode, haciendo que sea más fácil para todos hacer las cosas de la manera más conveniente.

Pero no, no tienes que hacerlo. No importa en muchos casos. Pero no hay mucha razón para no hacerlo, así que lo recomiendo.