Connexion

Salut tout le monde. Je suis en train de refactoriser une partie de mon code qui gère les états d’une application et je me retrouve avec deux approches qui semblent toutes les deux fonctionner, mais je ne sais pas laquelle est vraiment plus maintenable sur le long terme. D’un côté, j’ai une classe bien structurée, de l’autre, un ensemble de fonctions pures avec un contexte partagé. Je n’arrive pas à trancher et ça me trotte dans la tête depuis deux jours. Est-ce que certains d’entre vous ont déjà eu ce genre d’hésitation sur la structuration du code ?

J ai souvent eu ce genre d hésitation sur les états de l application et j avoue que c est pas simple. Une classe bien structurée peut aider a maintenir les invariants et a clarifier les responsabilités, mais elle peut aussi figer certaines habitudes et compliquer les tests. Un ensemble de fonctions pures avec un contexte partagé peut offrir de la souplesse, mais la traçabilité des évolutions devient peut être plus fragile. Tu es en train de peser quoi entre lisibilité et modularité, ou est ce juste la préférence personnelle

Franchement est ce que ce choix entre classe et fonctions pures change vraiment quelque chose a long terme ou est ce juste ce que l on préfère lire ? personnellement j ai l impression que tout dépend plus du contexte de ton équipe et des tests que d une règle absolue. les attentes des lecteurs et les habitudes liées au style de code peuvent influencer les états et la façon dont vous les manipulez

Le vrai enjeu ici n est pas juste classe ou fonctions mais ce que cela fait naitre comme contraintes sur les tests et les migrations des états. Si on empile des états dans un contexte partagé on peut gagner en API légère mais on peut aussi rater des invariants et compliquer les évolutions. Peut etre que l essentiel est de penser a des contrats clairs et a des tests qui montrent les chemins possibles des états plutot que de chercher une solution parfaite

Connexion
Nom d’utilisateur
Mot de passe	Mot de passe oublié ?
	Se souvenir de moi