Categorías en NSObject - mantiene a salvo

Question

de Apple tiene this to say:

Categorías de la raíz Clase

Una categoría puede añadir métodos a una clase, incluyendo la clase raíz. Los métodos agregados a NSObject estarán disponibles para todas las clases vinculadas a su código. Agregar métodos a la clase raíz con una categoría puede ser útil a veces, pero también puede ser bastante peligroso. Aunque puede parecer que las modificaciones que hace la categoría son bien entendidas y de impacto limitado, la herencia les da un amplio alcance. Puede estar haciendo cambios involuntarios a clases no vistas en su aplicación; es posible que no sepa todas las consecuencias de lo que está haciendo. Además, otros que trabajan en su aplicación, que desconocen sus cambios, no entenderán lo que están haciendo.

Mi pregunta es: si elijo nombres de métodos que sean lo suficientemente raros como para estar seguro de que nadie más los usará (ni en Apple ni en mi proyecto), ¿puedo tener problemas? ¿Podría haber un comportamiento inesperado? Implicaciones de rendimiento?

Answer 1

Si realmente está seguro de que Apple nunca agregará un método de ese nombre, es seguro. Si desea , haga cumplir que sin embargo, prefijo el nombre del selector. Por ejemplo, Adium en un punto agregó un método -setObject:atIndex: a NSMutableArray (sí, solo un contenedor "cosmético" sobre el método API existente -replaceObject:atIndex. Muy inútil) ... resultó tener el mismo nombre que un método interno, y veeeeery semántica ligeramente diferente. Esto causó bloqueos, pero solo en ciertos sistemas operativos. Si hubiera sido llamado algo así como -AISetObject:atIndex: hubiera estado bien.

Las implicaciones de rendimiento para las categorías son mínimas. No me preocuparía por ese aspecto.

Answer 2

Si los nombres de sus métodos no entran en conflicto con nada, y las personas que los usan saben lo que hacen, no debería tener ningún problema. Recuerde, una categoría agrega métodos adicionales, pero no variables de instancia para una clase. Una subclase es más flexible y se trata como un objeto completo, que responde a todos los métodos de superclase más propios. Yo diría que haga una subclase a menos que no pueda o sea inconveniente hacerlo. Las categorías fueron hechas para ser usadas, después de todo. Usualmente uso categorías cuando tengo un marco y necesito agregar métodos privados a una clase declarada públicamente.