Por ejemplo, si se produce un 'manejar todo' método de tipo ...iPhone, ¿está utilizando isKindOfClass como una mala práctica de alguna manera?
if ([obj isKindOfClass:class1]) {
// ...
} else if ([obj isKindOfClass:class2]) {
// etc..
¿Es esta mala práctica? ¿Hay una alternativa más ordenada o una mejor manera de estructurar el código?
¿Hay desventajas en los tiempos de ejecución, legibilidad, mantenibilidad o algo así?
Cuando algo es se considera buena/mala práctica, es más o menos subjetivo. Al hacer algo es intrínsecamente correcto/incorrecto, es más o menos objetivo.
isKindOfClass: es un método útil para verificar la herencia de clases. Responde a la única pregunta, "¿es el objeto de una clase que es (una subclase de) una clase determinada?". No responde ninguna otra pregunta como "¿este objeto implementa ese método a su manera?" o "¿Puedo usar el objeto para X o Y?". Si usa isKindOfClass: según lo previsto, no tendrá ningún problema. Después de todo, en un lenguaje de tipado dinámico, debe tener herramientas para extraer metainformación sobre los objetos. isKindOfClass: es solo una de las herramientas disponibles.
El hecho de que ciertos objetos mientan sobre su clase no debería desanimarlo. Simplemente se disfrazan como objetos de otra clase sin romper nada. Y si eso no rompe nada, ¿por qué debería importarme?
Lo principal es que siempre debe recordar usar la herramienta correcta para cualquier propósito. Por ejemplo, isKindOfClass: no sustituye a respondsToSelector: o conformsToProtocol:.
Tipo de. Esta pregunta básicamente cubre lo que estás preguntando: Is it safe to use isKindOfClass: against an NSString instance to determine type?
Hay algunas advertencias que debes tener en cuenta (ver enlace arriba), pero personalmente creo que es un método bastante legible. Solo necesitas asegurarte de que lo que estás haciendo dentro de tu prueba condicional es apropiado (el ejemplo de Apple es como "un objeto puede decir es una especie de NSMutableArray, pero es posible que no puedas mutarlo")
Considero que el ejemplo que dio es un antipatrón, así que sí, diría que es perjudicial. Usar isKindOf de esa manera está derrotando el polimorfismo y la orientación del objeto.
que ahora preferiría que se llama:
[obj doTheThing];
y luego implementar doTheThing diferente en sus subclases.
Si obj podría pertenecer a clases que no tiene control, use categorías para agregar su método doToThing a ellas. Si necesita un comportamiento predeterminado, agregue una categoría en NSObject.
Esta es una solución más limpia en mi opinión, y ayuda a separar la lógica (lo que está haciendo) de los detalles de implementación (cómo hacerlo para diferentes tipos de objetos específicos).
La implementación de métodos en categorías para evitar la necesidad de utilizar herramientas de introspección me suena peor. iE NSJSONSerialization 'JSONObjectWithData: options: error:' podría devolver diferentes tipos. (Matriz, diccionario).piratear el método del diccionario en arreglos y viceversa suena extremadamente estúpido para mí. – vikingosegundo
¿Qué pasa si solo una subclase necesita tener un método? –
Si solo una subclase necesita tener un método, entonces tiene un método en la clase base con una implementación predeterminada que no hace nada, y un método reemplazado en la subclase que hace algo. –