Salut à tous, j’ai une question un peu bête peut-être. Je travaille sur un petit projet perso en Python, et je me retrouve souvent à écrire des fonctions qui font à peu près la même chose mais pour des types de données légèrement différents. Je me demande si je devrais me forcer à tout refactoriser en une seule fonction générique avec des types, ou si c’est acceptable de laisser tel quel pour garder la simplicité. J’ai l’impression de passer plus de temps à me poser la question qu’à coder, et ça me ralentit. Quelqu’un a déjà eu ce genre d’hésitation sur quand il est pertinent d’introduire du polymorphisme ?
|
Comment décider entre refactoriser en générique ou garder le code simple ?
|
|
Pour moi le vrai critère c est la duplication de logique et l intention. Le polymorphisme peut permettre dextraire ce qui est commun et lire le code comme une histoire cohérente mais il peut aussi rendre le chemin plus flou. Si tu écris trois fonctions qui font sensiblement la même chose en n adaptant que les types c est peut etre le signe d introduire une fonction générique ou un protocole qui capture le contrat commun. Pense aussi a l impact sur les tests et sur la lisibilité est ce que cela réduit les branches ou au contraire cela les multiplie Tu as l impression que le coût de la généralisation est compensé par la réutilisation sur le long terme
J ai été dans ce dilemme si ca marche rapidement pourquoi toucher au code Le polymorphisme a son prix plus d abstraction plus de surprises lors des lectures Parfois garder des petites fonctions separées est plus clair et plus rapide a écrire Tu es pressé par le temps mais est ce que le coût de la complexité vaut le gain de réutilisation sur le long terme
Je me suis retrouvé dans ce cas avec des transformations appliquees a des types proches J ai laissé faire quand les comportements divergeaient vraiment et que l abstraction était lourde sans gagner en lisibilite Puis j ai ajoute une légère couche d abstraction la ou cela facilita l extension et j ai renforce le tout avec des tests C est parfois un compromis entre simplicité et polyvalence
On dirait que certains lecteurs attendent que le code ressemble a un roman coherent motifs recurents progression claire et des choix qui semblent coherents Le polymorphisme peut pousser a parler en termes de protocoles et de comportements plutot qu en fonction des simples types ce qui change aussi le style d ecriture du code Les attentes des contributeurs jouent alors un role est ce que le code se lit comme une solution prête a evoluer ou comme une pierre brute a polir
Parfois une fonction qui accepte des objets avec les methodes attandues suffit c est simple rapide et assez robuste tant que les contrats restent stables Le risque c est d abuser de l abstraction et de perdre en clarte mieux vaut viser la simplicite quand le gain de rel utilisation n est pas evident
Reformulation on ne parle pas uniquement de polymorphisme ou de refactorisation mais de savoir quand anticiper le changement et quand rester pragmatique avec des solutions ciblees Qu est ce qui justifie d etendre une API ou dintroduire des abstractions quand les exigences actuelles restent simples
|
|
« Sujet précédent | Sujet suivant »
|

