Le surcoût de la méthode objective-c rend-il une approche de conception de «nombreuses petites méthodes» déconseillée?

Je préfère généralement utiliser de petites méthodes, comme recommandé, entre autres, par Bob Martin dans Clean Code . J'ai également lu suffisamment de choses sur les internes d'Objective-C pour avoir au moins une idée du fonctionnement de l'envoi de messages (la série bbums est particulièrement informative à ce sujet).

Nonobstant les problèmes d'optimisation prématurée, j'aimerais savoir si tout le travail qu'Objective-c fait avec objc_msgSend est, en termes pratiques, suffisamment important pour que l'approche des `` nombreuses petites méthodes '' soit déconseillée pour les projets Objective-C.

Les découvertes empiriques sont particulièrement les bienvenues (je vais peut-être mettre en place un test moi-même un jour). L'expérience de quiconque a écrit de grands projets objectifs-c serait également formidable.

Clarification

Le ton général de la question est intentionnel. Je ne pose pas de question sur le réglage des performances d'applications spécifiques (c'est pourquoi je pose la question ici plutôt que sur SO), mais plutôt sur si les caractéristiques du langage d'Objective-C découragent une certaine approche de conception. J'ai observé qu'une grande partie du code que j'ai vu d'Apple et d'autres parties (sur github, etc.) tend vers de grandes méthodes (et classes), et je me demande si c'est un biais qui s'est glissé à cause du langage lui-même. Bien sûr, j'ai peut-être lu le mauvais code, ou ce sont peut-être des facteurs culturels plutôt que techniques qui ont conduit à la tendance si elle existe.

(Pour ce que ça vaut, j'écris actuellement Objective-C, et j'utilise de petites méthodes)

Demande complémentaire

Je suis d'accord avec les deux réponses qui ont été données. Une autre chose que j'aimerais, c'est que quelqu'un me pointe vers une base de code Objective-C open-source (espérons-le substantielle) (ou autrement visible) qui utilise de belles méthodes courtes (et de petites classes). Je n'ai encore rien vu dans Objective-C à comparer avec (par exemple) la source fitnesse .

design coding-style objective-c

— Cris
source

Mike Ash a quelques beaux articles montrant des chiffres pour Leopard et iOS . Je ne les ai pas entièrement digérés, mais il semblerait que pour les IMP mis en cache, la surcharge est négligeable, et même dans les envois nécessitant une recherche, elle est assez petite. Si cette impression rapide est juste, il semblerait que de petites méthodes puissent se tenir ou tomber sur les mêmes motifs de conception dans ObjC que dans tout autre langage.

— Cris

Si vous voulez éviter cette surcharge, utilisez les fonctions C.

— replié à droite

Techniquement possible, mais beaucoup de choses sont perdues avec les fonctions. Je ne remplacerais les méthodes que par des fonctions pour des portions de code ciblées et sensibles aux performances. Je demande ici si la surcharge est suffisamment problématique pour reconsidérer un style de codage / conception préféré.

— Cris

Voir Coût de l'envoi des messages dans Objective-C sur SO pour de bonnes réponses.

— Caleb

Pourquoi ne profilez-vous pas simplement votre code dans Xcode? Je comprends que vous posez des questions dans l'abstrait et non sur un code spécifique, mais puisque vous avez apparemment du code avec beaucoup de petites méthodes, pourquoi ne pas l'exécuter et voir par vous-même?

— Caleb

Réponses:

Je ne sais pas vraiment si les frais généraux sont négligeables ou non. Mais, je préférerais concevoir un système pour être facilement compréhensible et maintenable en premier , et cela signifie normalement de petites méthodes et classes ciblées. Cela vous aidera même à régler le code ultérieurement (simplement parce que le code est plus facile à maintenir). En outre, il est important de profiler le code pour trouver de véritables goulots d'étranglement, qui pourraient même ne pas être liés à la surcharge des appels de méthode. Si vous effectuez des opérations hors processus (par exemple, des appels à une base de données, un réseau, un système de fichiers), celles-ci ont de toute façon tendance à dominer l'exécution du programme.

Mais, comme d'habitude, votre kilométrage peut varier ...

— Jordão
source

Bien sûr, je suis d'accord avec tout cela (voir la référence «Oncle Bob» dans la question). Mais si un langage ne se prête généralement pas à une certaine approche de conception dans le meilleur des cas, les programmeurs peuvent faire d'autres choix. Je n'ai pas vu beaucoup de code Objective-C qui suit vraiment les petites méthodes (et les classes, d'ailleurs), et je me demande pourquoi. Je vais ajouter une note à la question.

— Cris

@Cris: "Je n'ai pas vu beaucoup de code Objective-C qui suit vraiment les petites méthodes" -> Juste curieux: de quel corps de code avez-vous tiré une telle conclusion? J'y crois, mais je crois aussi que ce n'est pas à cause de la sensibilisation à la micro-optimisation, mais davantage de programmeurs ne se concentrant pas sur les principes d'une bonne conception et de la maintenabilité. Autrement dit, leur Java, C #, Ruby ou tout autre code doit suivre les mêmes pratiques ...

— Jordão

Oui, c'est tout à fait possible. Je n'avais aucune base de code spécifique en tête; juste ce que j'ai regardé au cours de l'année ou alors j'ai travaillé avec Objective-C. Le plus grand ensemble de code que j'ai examiné était le contenu open source du groupe Omni, et l'IIRC qui avait beaucoup de grandes méthodes. L'exemple de code d'Apple le fait aussi souvent. Mais bien sûr (a) l'exemple de code n'est que cela, et (b) mon échantillon peut être pondéré vers le code de l'interface utilisateur, les contrôleurs de vue en particulier, et ceux-ci peuvent être codés différemment des couches plus profondes.

— Cris

La grande majorité du code ne sera pas critique en termes de performances dans aucune application, donc même si la surcharge de méthode était significative par rapport à d'autres langages, l'approche optimale serait toujours d'avoir de nombreuses petites méthodes dans la plupart des endroits et de n'inclure que celles qui profilent s'est avéré essentiel aux performances.

Bien sûr, il y a beaucoup de gens qui ne savent pas comment optimiser correctement, et parmi ceux-ci certains peuvent connaître les frais généraux de la méthode et s'engager dans des actes d'optimisation prématurée globale, mais je ne pense pas que le groupe soit assez grand pour avoir un impact significatif sur l'écosystème Objective-C.

Les grandes méthodes et les classes sont beaucoup plus susceptibles d'être l'œuvre d'un grand groupe de personnes qui ne connaissent pas les profileurs, les frais généraux de méthode ou la conception appropriée, et qui auront tendance à produire de grosses boules de boue dans n'importe quelle langue. Et oui, certaines de ces personnes travaillent sur des bases de code de haut niveau dans les principales sociétés de logiciels.

— Michael Borgwardt
source