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

15

Por lo general, prefiero usar métodos pequeños, como lo recomiendan, entre otros, Bob Martin en Clean Code . También he leído lo suficiente sobre los aspectos internos de Objective-C para tener al menos una idea de cómo funciona el envío de mensajes ( bbums series es particularmente informativo 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' no sea aconsejable para proyectos Objective-C.

Los hallazgos empíricos son particularmente bienvenidos (tal vez en algún momento me haga una prueba). La experiencia de cualquiera que haya escrito grandes proyectos de object-c también sería excelente.

Clarificación

El tono general de la pregunta es intencional. No estoy preguntando sobre el ajuste de rendimiento de aplicaciones específicas (por lo que pregunto aquí en lugar de SO), sino más bien si las características de lenguaje de Objective-C desalientan 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 a los grandes métodos (y clases), y me pregunto si este es un sesgo que se ha arrastrado debido al lenguaje. sí mismo. Por supuesto, es posible que haya estado leyendo el código incorrecto, o que sean factores culturales más que técnicos que hayan llevado a la tendencia, si existe.

(Para 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 una base de código Objective-C de código abierto (ojalá que sea visible) que use métodos cortos (y clases pequeñas). Todavía no he visto nada en Objective-C para compararlo con (por ejemplo) la fitnesse source .

    
pregunta Cris 25.10.2011 - 23:08
fuente

2 respuestas

4

Realmente no sé si los gastos generales son insignificantes o no. Pero, preferiría diseñar un sistema para que sea fácilmente comprensible y mantenible primero , y eso normalmente significa clases y métodos pequeños y enfocados. Esto también ayudará con el posterior ajuste del código (solo porque el código es más fácil de mantener). Además, es importante crear un perfil del código para encontrar cuellos de botella reales, que pueden no estar relacionados con la sobrecarga de llamadas a métodos. Si realiza alguna operación 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 de todos modos.

Pero, como es habitual, su kilometraje puede variar ...

    
respondido por el Jordão 27.10.2011 - 17:24
fuente
2

La gran mayoría de los códigos no serán críticos para el rendimiento en ninguna , por lo que incluso si la sobrecarga del método fuera significativa en comparación con otros idiomas, el enfoque óptimo sería tener muchos recursos pequeños. métodos en la mayoría de los lugares y en línea solo aquellos que los perfiles han demostrado ser críticos para el rendimiento.

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

Es mucho más probable que los métodos y clases grandes sean el trabajo de un gran grupo de personas que no conocen o no se preocupan por los perfiladores, el diseño adecuado del método o , y que tienden 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.

    
respondido por el Michael Borgwardt 27.10.2011 - 22:40
fuente

Lea otras preguntas en las etiquetas