Razones para usar las constantes de NSString sobre las enumeraciones

Question

Me pregunto por qué Apple está utilizando (bastante en CoreAnimation, pero también en otras partes) las constantes que se declaran como NSString * const como por ejemplo kCAGravityTop en lugar de las enumeraciones regulares? ¿Qué tal tipo de seguridad en este caso? Tal como lo entiendo, uno podría pasar cualquier NSString a un método esperando esta constante sin recibir ninguna advertencia del compilador.

Answer 1

No estoy seguro, pero supongo que tiene que ver con que los usuarios agreguen sus propias extensiones y subclases a algunas de las cosas de Apple. En ese caso, puede anular el método utilizado y detectar el caso donde la cadena es "MyOwnValue" y luego hacer lo que quiera con ella. Esto es significativamente más fácil que tener que modificar la enumeración de Apple, y también evita que se arruine todo.

También podría ser para facilitar que Apple tenga independencia de versión. Con enumeraciones, si reorganiza su orden de alguna manera, puede causar muchos problemas para cualquiera de sus valores que se han almacenado en caché (por la razón que sea). Si el valor de la enumeración es 1 < < 3 cuando se guarda en un archivo, Apple agrega otra enumeración para que su valor sea ahora 1 < < 4, entonces, obviamente, lo que está saliendo mal es su programa. ¿Por qué no tendrían cuidado de mover los valores enum, no lo sé, pero creo que es muy probable que hayan usado NSString porque no hay forma de que su valor u orden se pueda cambiar en cualquier versión.

Answer 2

Sospecho que el motivo es histórico o estilístico más que cualquier otra cosa. Así es como lo hicieron los marcos NeXT y crearon el "estilo" Cocoa. Como beneficio de este enfoque, inspeccionar el valor en el depurador puede dar un valor significativo (por ejemplo, @ "CAGravityTop" o algo así en lugar de un sentido int). Debido a que el compilador maneja las cadenas estáticas de manera inteligente, la comparación puede ser mediante comparación de punteros en lugar de igualdad de cadenas (vea la respuesta de bbum), por lo que este enfoque tiene un rendimiento insignificante.

Answer 3

Los tipos enumerados no se pueden extender sin agregar entradas adicionales dentro del tipo enumerado. Por lo tanto, es imposible tener contenidos de enumeración que sean tratados como un miembro formal del tipo enumerado, pero tampoco son visibles durante la compilación normal.

Tome CoreAnimation, por ejemplo. Puede haber valores que se usan internamente que no son compatibles o están disponibles a través de la API pública por una variedad de razones; El "detalle de la implementación" viene inmediatamente a la mente.

Más allá de eso, las cadenas como constantes permiten la extensión como implica Eli. También tienden a ser mucho más informativos cuando se depuran. "kCAGravityTop" es mucho más indicativo que, por ejemplo, "4".

En términos de rendimiento, hay muy poca penalización al uso de cadenas. El compilador maneja de manera eficiente las cadenas estáticas, de las cuales se compone en realidad la contraparte interna de cada constante de cadena, y la primera prueba del método -isEqualToString: es la igualdad del puntero, muy rápido. No tan rápido como un interruptor(), pero dada la magnitud de la ejecución del código implicada por la constante, la diferencia de pocos ciclos entre el interruptor() y la comparación de la cadena es irrelevante.

Answer 4

Una de las razones más pensaba en favor de NSString es que puede pasar alrededor de donde id se acepta (como userInfo o como teclas de diccionario) mientras que los tipos primitivos (enumeraciones) necesitarían algún tipo de envoltorio para este