J'ai grandi en jouant à Magic : the Gathering. Quand j'étais enfant, j'ai remarqué quelque chose d'intéressant à propos des noms de cartes : il n'y avait pas de noms génériques. Il n'y avait aucune carte nommée "Zombie", "Elfe" ou "Magicien". Il y avait des cartes nommées « Fugitive Wizard », « Llanowar Elves », « Gravebane Zombie » et même « Storm Crow » mais pas de « Crow ». Les noms de cartes modernes sont encore plus spécifiques et évocateurs ; témoin « Crow of Dark Tidings » et « Flameheart Werewolf ». Pourquoi? Parce que les concepteurs doivent laisser de la place pour de nouvelles cartes. S'il y avait une carte nommée « Zombie », c'est bien celle-là. Cette carte montre ce qu'est un zombie. Si vous souhaitez créer une autre carte zombie, elle vivra dans l’ombre du « Zombie » original.
Cela a des applications en génie logiciel. Les noms que nous choisissons pour les classes définissent la façon dont nous les considérerons et le type de responsabilités que nous leur attribuerons. Si vous avez une classe nommée User, alors il est logique de mettre les éléments liés au concept « d'utilisateur » dans cette classe. C'est un problème cependant. Il est logique de mettre quoi que ce soit d'artificiel lié à ce concept sur la classe User. Vous obtiendrez des informations de connexion, des préférences de facturation, des paramètres de messagerie et des autorisations. On sait depuis longtemps que les grandes classes posent problème. Ils sont plus difficiles à lire car ils ont plus de logique au même endroit, ils sont plus difficiles à modifier car la logique est plus susceptible d'être entremêlée, et cela les rend plus susceptibles d'être bogués.
Les noms de classe préparent le terrain pour la logique que la classe développe au fil du temps. Nous devons nous rappeler que nous n’écrivons pas du code une seule fois et que c’est ensuite terminé. Le code évolue continuellement et est continuellement modifié pour répondre aux nouveaux besoins. À chaque étape, les développeurs se demanderont : « où cette logique a-t-elle du sens ? Comme l'a noté Stephen Wolfram, « les noms des fonctions… déterminent directement la façon dont les gens penseront à une fonction. « Les développeurs considéreront les noms de classe comme un signe indiquant la place de la logique. Ils considéreront le concept incarné par la classe comme un autre. Si le nom et le concept sont larges, les développeurs mettront de nombreux éléments de logique dans la classe.
Un autre point à souligner à propos des noms de classes génériques est qu'ils ne sont pas descriptifs. Si vous ouvrez une classe nommée User, vous n'avez pas une idée immédiate des données qu'elle peut contenir. Il peut contenir beaucoup de choses. Vous devrez le relire pour le savoir et vous en souvenir pour la prochaine fois. Cela impose une charge cognitive importante aux développeurs en activité. Ils doivent garder à l’esprit les détails des classes nombreuses ou bien les relire pour s’en assurer. Si le nom ressemblait à LoginCredentials, alors ce qu'il contiendra est assez évident. Le nom guide le lecteur en délimitant le rôle de la classe.
Nous devrions chercher à ce que notre code fournisse un riche ensemble d’indices pour se faire comprendre. Les noms constituent une pièce importante du puzzle. En s'inspirant de Magic : the Gathering, si nous essayons de renommer User avec un nom plus évocateur, nous nous rendrons vite compte qu'il faut le séparer. Nous nous retrouverons probablement avec des classes plus petites et plus ciblées, ce qui est également une aubaine.