¿La sobrecarga del método del objetivo-c hace desaconsejable un enfoque de diseño de 'muchos métodos pequeños'?

En general, estoy a favor de utilizar métodos pequeños, como lo recomienda, entre otros, Bob Martin en Clean Code . También he leído lo suficiente sobre las partes internas de Objective-C para tener al menos una idea de cómo funciona su envío de mensajes (la serie de álbumes es particularmente informativa sobre esto).

A pesar de las preocupaciones de optimización prematura, me gustaría saber si todo ese trabajo que Objective-c hace con objc_msgSend es, en términos prácticos, lo suficientemente significativo como para que el enfoque de 'muchos métodos pequeños' sea desaconsejable para proyectos de Objective-C.

Los hallazgos empíricos son particularmente bienvenidos (tal vez yo mismo haga una prueba alguna vez). La experiencia de cualquiera que haya escrito grandes proyectos de Objective-C también sería excelente.

Aclaración

El tono general de la pregunta es intencional. No estoy preguntando sobre el ajuste de rendimiento de aplicaciones específicas (por eso pregunto aquí en lugar de en SO), sino más sobre si las características del lenguaje de Objective-C desalientan un cierto enfoque de diseño. He observado que gran parte del código que he visto de Apple y otras partes (en github, etc.) tiende hacia métodos grandes (y clases), y me pregunto si esto es un sesgo que se ha introducido debido al lenguaje sí mismo. Por supuesto, puede que haya estado leyendo el código incorrecto, o pueden ser factores culturales más que técnicos que han llevado a la tendencia si existe.

(Por lo que vale, actualmente estoy escribiendo Objective-C, y estoy usando métodos pequeños)

Solicitud adicional

Estoy de acuerdo con las dos respuestas que se han dado. Otra cosa que me gustaría es que alguien me señale a una base de código Objective-C de código abierto (con suerte sustancial) (o visible) que use buenos métodos cortos (y clases pequeñas). Todavía no he visto nada en Objective-C para comparar con (por ejemplo) la fuente fitnesse .

design coding-style objective-c

— Cris
fuente

Mike Ash tiene algunas buenas publicaciones que muestran números para Leopard e iOS . No los he digerido completamente, pero parece que para los IMP en caché la sobrecarga es insignificante, e incluso en los despachos que requieren búsqueda, es bastante pequeña. Si esta impresión rápida es correcta, parecería que los métodos pequeños podrían sostenerse o caer en los mismos motivos de diseño en ObjC que en cualquier otro idioma.

— Cris

Si desea evitar esa sobrecarga, use las funciones de C.

— pliegue derecho

Técnicamente posible, pero mucho se pierde con las funciones. Solo reemplazaría los métodos con funciones para porciones de código específicas y sensibles al rendimiento. Estoy preguntando aquí si la sobrecarga es lo suficientemente problemática como para reconsiderar un estilo de codificación / diseño preferido.

— Cris

Consulte Costo de envío de mensajes en Objective-C en SO para obtener algunas buenas respuestas.

— Caleb

¿Por qué no simplemente perfilas tu código en Xcode? Entiendo que estás preguntando en abstracto y no sobre un código específico, pero como aparentemente tienes un código con muchos métodos pequeños, ¿por qué no ejecutarlo y verlo por ti mismo?

— Caleb

Respuestas:

Realmente no sé si los gastos generales son insignificantes o no. Pero, preferiría diseñar un sistema para que sea fácil de entender y mantener primero , y eso normalmente significa métodos y clases pequeños y enfocados. Esto incluso ayudará con el ajuste de código posterior también (solo porque el código es más fácil de mantener). Además, es importante perfilar el código para encontrar cuellos de botella reales, que podrían no estar relacionados con la sobrecarga de llamadas al método. Si realiza operaciones fuera del proceso (por ejemplo, llamadas a la base de datos, la red, el sistema de archivos), estas tienden a dominar el tiempo de ejecución del programa.

Pero, como siempre, su kilometraje puede variar ...

— Jordão
fuente

Por supuesto, estoy de acuerdo con todo esto (ver la referencia del 'Tío Bob' en la pregunta). Pero si un lenguaje no se presta en general a un cierto enfoque de diseño del mejor de los casos, los programadores podrían tomar otras decisiones. No he visto mucho código Objective-C que realmente siga los métodos pequeños (y el enfoque de clases, para el caso), y me pregunto por qué. Agregaré una nota a la pregunta.

— Cris

@Cris: "No he visto mucho código Objective-C que realmente siga los pequeños métodos" -> Solo curiosidad: ¿de qué cuerpo de código sacaste tal conclusión? Creo en ello, pero también creo que no se debe a la conciencia de la microoptimización, sino a que más programadores no se centran en los principios del buen diseño y mantenimiento. Dicho de otra manera, su código Java, C #, Ruby o cualquier otro debe seguir las mismas prácticas ...

— Jordão

Sí, eso es muy posible. No tenía ninguna base de código específica en mente; justo lo que he visto durante el año más o menos, he trabajado con Objective-C. El conjunto de código más grande que he visto fue el material de código abierto del grupo Omni y el IIRC que tenía muchos métodos grandes. El código de muestra de Apple también lo hace a menudo. Pero, por supuesto, (a) el código de muestra es solo eso, y (b) mi muestra puede ser ponderada hacia el código de la interfaz de usuario, en particular los controladores de vista, y estos pueden codificarse de manera diferente a las capas más profundas.

— Cris

La gran mayoría del código no será crítico para el rendimiento en ninguna aplicación, por lo que incluso si la sobrecarga del método fuera significativa en comparación con otros lenguajes, el enfoque óptimo sería tener muchos métodos pequeños en la mayoría de los lugares e incluir solo aquellos que crean perfiles ha demostrado ser crítico para el rendimiento.

Por supuesto, hay muchas personas que no saben cómo optimizar adecuadamente, y algunas de ellas pueden saber sobre la sobrecarga del método y participar en actos de optimización global prematura, pero no creo que ese grupo sea lo suficientemente grande como para tener un impacto significativo en el ecosistema Objective-C.

Es mucho más probable que los métodos y clases grandes sean el trabajo del gran grupo de personas que no saben o no se preocupan por los perfiladores, la sobrecarga del método o el diseño adecuado, y que tenderán a producir Big Balls of Mud en cualquier idioma. Y sí, algunas de esas personas trabajan en bases de código de alto perfil en las principales compañías de software.

— Michael Borgwardt
fuente