Pragmatisme ou pureté - Devrions-nous compter sur le cadre GUI pour stocker l'état du programme?

Question

J'ai été une fois chargé de créer un contrôle utilisateur personnalisé C#. C'est un contrôle avec un tas de sections pliables. Le contrôle sur lequel l'utilisateur peut cliquer pour basculer entre l'état de réduction/d'expansion est un contrôle d'étiquette. Il y a un contrôle d'image juste à côté qui change d'état pour indiquer si la section particulière est réduite ou agrandie. Quelque part dans le contrôle, j'ai besoin d'une fonction pour retourner l'état d'une section particulière. La question est la suivante: la fonction doit-elle retourner l'état en fonction de l'état du contrôle d'image ou doit-on introduire une variable supplémentaire qui stocke l'état, avec le risque supplémentaire d'être désynchronisé avec l'état actuel?

Answer 1

La plupart du temps, lorsque les gens vont avec une solution «pure» à des problèmes comme ceux-ci, ils cachent simplement le couplage, sans le retirer. Le couplage représente généralement la complexité essentielle du problème qu'ils tentent de résoudre. Comme il ne peut pas être retiré, il peut aussi bien être mis en œuvre de manière directe.

Votre cas ne fait pas exception. Sauf si vous pensez qu'il y a une chance décente que le getter de l'état du contrôle de l'image change dans le futur (pas si vous utilisez un framework stable), en utilisant une variable supplémentaire qui est toujours supposée avoir la même valeur que celle du contrôleur d'image l'état remplace simplement le couplage explicite avec un couplage implicite légèrement caché. Cela ne vous apporte rien et augmente la complexité et donc le potentiel de bug.

Answer 2

La redondance est inutile. Je dis juste lire l'état de l'image, si cela peut être considéré comme empirique.