Avis sur structure de code

Salut à tous,
J'ai un soucis avec un code écrit par un ami et je voudrais avoir votre avis sur le sujet.
Dans son développement (en c#), il à une méthode mA implémentée dans une classe A qui appelle (à l'intérieure de la méthode) une méthode mB implémentée dans une classe B. Cette méthode mB appelle à son tour une méthode mC implémentée dans un troisième classe C, la méthode mC appelle aussi une classe mD implémentée dans une classe D (ouf!! enfin).
A part le fait que cela complique la maintenance du code, cette pratique influencera t-elle la rapidité d'exécution de son application ? vue que cette application doit tourner 24h/24 (service Windows).
Merci de vos réponses.

un appel doit perdre quelques pouillèmes de microseconde
donc non

quant à la complication, moi je préfère voir 4 méthodes qui font un truc distinct et simple qu'une grosse méthode fourre tout
mais bon c'est à voir selon le code contenu ...

Merci de ta réponse.
Je suis entièrement d'avis avec toi sur le fait qu'il faut morceler le code mais c'est un peu trop à mon avis, non ?

Cela dépend du contexte, tant qu'il respecte le SRP (définition : https://en.wikipedia.org/wiki/Single...lity_principle).
Dépend si c'est du static, si y a de l'instance, après peut-être que certaines méthodes pourraient être mises dans la même classe. Après si c'est pour se retrouver avec 40 propriétés non merci.
Plus on divise le code meilleure la gestion des bug est. Après dépend aussi si les méthodes font 5 lignes ou 40 lignes, pour pas avoir un fichier trop gros on essaye de les diviser.

toutes ces classes et méthodes sont static. Cela pose-t-il un problème ??

Citation:

---

Envoyé par Pol63

un appel doit perdre quelques pouillèmes de microseconde

---

En fait moins de 5 ns. ;)

Citation:

---

Envoyé par devvanjier

Je suis entièrement d'avis avec toi sur le fait qu'il faut morceler le code mais c'est un peu trop à mon avis, non ?

---

La seule question est de savoir si le découpage du code est logique et si tu peux proposer une meilleure alternative.

En général il est bon de découper le problème en sous-problèmes. Ça ne veut pas dire pour autant multiplier des micro-classes et donc multiplier la plomberie (repasser en argument ce qui était stocké sur la classe appelante, etc).

Le SRP et autres principes fournissent une bonne grille de lecture au plus haut niveau du code. Mais à plus bas niveau il est parfois plus pragmatique de regarder la taille de la classe : si celle-ci excède quelques dizaines de lignes il est bon de se demander si l'on peut efficacement découper. En-dessous c'est souvent couper les cheveux en quatre et produire un code "en grains de riz".

Quant aux fonctions il est préférable de les garder en-dessous de dix lignes.

Merci à vous d'avoir éclairé ma lanterne
:D