A sobrecarga do método do objetivo-c torna desaconselhável uma abordagem de design de 'muitos métodos pequenos'?

Geralmente sou a favor do uso de métodos pequenos, como recomendado por Bob Martin no Clean Code , entre outros . Também li o suficiente sobre os internos do Objective-C para ter pelo menos uma idéia de como funciona o envio de mensagens (a série bbums é particularmente informativa sobre isso).

Apesar da otimização prematura, eu gostaria de saber se todo o trabalho que o Objective-c faz com objc_msgSend é, em termos práticos, significativo o suficiente para que a abordagem de 'muitos métodos pequenos' seja desaconselhável para projetos de Objective-C.

Achados empíricos são particularmente bem-vindos (talvez eu mesmo faça um teste algum dia). A experiência de quem já escreveu grandes projetos de objetivo-c também seria ótima.

Esclarecimento

O tom geral da pergunta é intencional. Não estou perguntando sobre o ajuste de desempenho de aplicativos específicos (é por isso que pergunto aqui, e não no SO), mas mais sobre se as características de linguagem do Objective-C desencorajam uma certa abordagem de design. Eu observei que grande parte do código que eu vi da Apple e de outras partes (no github etc) tende a métodos (e classes) grandes, e estou me perguntando se esse é um viés que surgiu por causa da linguagem. em si. É claro que eu posso estar lendo o código errado, ou pode ser fatores culturais e não técnicos que levaram à tendência, se ela existir.

(Pelo que vale a pena, atualmente estou escrevendo Objective-C e usando métodos pequenos)

Pedido adicional

Eu concordo com as duas respostas que foram dadas. Outra coisa que eu gostaria é que alguém me aponte para uma base de código Objective-C de código-fonte aberto (que é substancialmente visível) (ou de outra forma visível) que usa métodos curtos e agradáveis ​​(e classes pequenas). Ainda não vi nada no Objective-C para comparar com (por exemplo) a fonte fitnesse .

Realmente não sei se a sobrecarga é insignificante ou não. Porém, eu preferiria projetar um sistema para ser facilmente compreensível e sustentável primeiro , e isso normalmente significa métodos e classes pequenos e focados. Isso também ajudará com o ajuste de código subsequente (apenas porque o código é mais sustentável). Além disso, é importante criar um perfil do código para encontrar gargalos reais, que podem até não estar relacionados à sobrecarga de chamada de método. Se você executar operações fora do processo (por exemplo, chamadas ao banco de dados, rede, sistema de arquivos), elas tendem a dominar o tempo de execução do programa de qualquer maneira.

Mas, como sempre, sua milhagem pode variar ...

A grande maioria do código não será crítica para o desempenho em nenhum aplicativo, portanto, mesmo que a sobrecarga do método fosse significativa em comparação com outras linguagens, a abordagem ideal ainda seria ter muitos métodos pequenos na maioria dos lugares e alinhar apenas aqueles que determinam o perfil. mostrou ser crítico para o desempenho.

Claro, existem muitas pessoas que não sabem como otimizar adequadamente, e algumas podem saber sobre sobrecarga de método e se envolver em atos de otimização prematura global, mas não acredito que o grupo seja grande o suficiente para ter um impacto significativo no ecossistema Objective-C.

É muito mais provável que métodos e classes grandes sejam o trabalho de um grande grupo de pessoas que não sabem nem se importam com criadores de perfil, sobrecarga de método ou design adequado e que tendem a produzir Big Balls of Mud em qualquer idioma. E sim, algumas dessas pessoas trabalham em bases de código de alto perfil nas principais empresas de software.