De if else pour passer du cas à l'abstraction

Selon vous, qu’est-ce qui rend les gens le plus impatients lorsqu’ils reprennent du code existant ? UML extrêmement complexe ? Je ne pense pas. Ma réponse est, si avec plus de deux cas, ou si vous changez avec plus de deux cas. Mais est-il normal d'utiliser beaucoup de if else et de changer de casse dans votre code ? faux! La plupart des cas if else et switch avec plus de deux branches ne doivent pas apparaître sous forme codée en dur.

D’où viennent les branches complexes ?

Tout d’abord, la première question que nous souhaitons aborder est de savoir pourquoi il existe souvent autant de branches complexes dans le code existant. Ces branches complexes n'existent souvent pas dans la première version du code. En supposant que le concepteur ait encore une certaine expérience, il doit prévoir les domaines qui pourraient devoir être étendus dans le futur et réserver les interfaces abstraites .

Cependant, après plusieurs itérations du code, notamment après plusieurs ajustements des détails des exigences, des branches complexes apparaîtront. Souvent, les ajustements détaillés des exigences ne sont pas reflétés dans UML, mais directement dans le code. Par exemple, les messages étaient initialement divisés en deux catégories : les messages de discussion et les messages système. Lors de la conception, ceux-ci ont naturellement été conçus comme deux sous-catégories de la catégorie des messages. Mais un jour, les exigences sont ajustées en détail. Certains messages du système sont importants et leurs titres doivent être affichés en rouge. À ce moment-là, les programmeurs effectuent souvent les modifications suivantes :

Ajouter un attribut important à la classe de message système

Ajoutez une branche sur l'attribut important dans la méthode de rendu correspondante pour contrôler la couleur du titre. Pourquoi le programmeur ferait-il un tel changement ? C'est peut-être parce qu'il n'a pas réalisé que cela devait être abstrait. Parce que l'exigence dit "certains messages système sont importants", pour les programmeurs qui ont reçu plus de formation dans les langages de programmation impératifs, la première chose à laquelle ils peuvent penser est le bit d'indicateur - un bit d'indicateur peut faire la distinction entre les messages importants et non importants. . important. Il ne s'attendait pas à ce que cette exigence puisse être interprétée d'une autre manière : « Les messages système sont divisés en deux catégories : importants et sans importance. En l'interprétant de cette façon, il savait que les messages du système devaient être abstraits.

Il est bien sûr possible que le programmeur sache que l'abstraction est possible, mais qu'il choisisse de ne pas le faire pour une raison quelconque. Une situation très courante est que quelqu'un oblige les programmeurs à sacrifier la qualité du code en échange de la rapidité de progression du projet. L'ajout d'une propriété et d'une branche est beaucoup plus simple que la refactorisation abstraite. Si vous souhaitez effectuer 10 modifications de cette forme, est-il plus rapide d'en créer 10. branches ou 10 abstractions ? La différence est évidente.

Bien sûr, s'il y en a trop, certaines personnes intelligentes se lèveront et diront : « Pourquoi ne pas le remplacer par un boîtier de commutation ? » Dans certains cas, cela peut réellement améliorer la lisibilité du code, en supposant que chaque branche s'exclut mutuellement. Mais lorsque le nombre de cas de commutation augmente, le code devient également illisible.

Quels sont les inconvénients des branches complexes ?

Quels sont les inconvénients des branches complexes ? Permettez-moi de prendre comme exemple une section de l'ancien code de la version Web de Baidu Hi.

Source : Expérience pan-utilisateur de Baidu