Il était une fois des programmeurs voulant nommer une classeDernièrement, moi et les autres membres de mon équipe de développement avions à prendre une décision sur le nom à donner à une nouvelle classe. À notre grande surprise, la réflexion a été plus difficile que prévue. Comme le dit l’expression, les deux des problèmes les plus difficiles dans le développement sont la mise en mémoire et l’action de nommer les choses.
Dans notre cas, nous n’arrivions pas à donner un nom à une nouvelle classe pour un projet en cours.
Pour vous mettre en contexte, il s’agissait d’une nouvelle version améliorée d’une classe existante. Cette classe sera déclarée en tant que classe dépréciée une fois la nouvelle complétée. La nouvelle classe corrige certains problèmes avec l’implémentation précédente en plus d’être rétrocompatible. Toutefois, notre principal souhait est de changer le nom utilisé par celle-ci, car elle entre en conflit avec une classe dans ASP.NET MVC.
Le nom de cette classe est UrlHelper. Dans MVC, elle permet de construire une URL en utilisant le contexte d’ASP.NET MVC. Par exemple, il est possible d’obtenir une URL de l’action d’un contrôleur en particulier.
Or, pour utiliser notre classe, à chaque endroit il faut avoir recours à une (à mes yeux) contorsion visuelle en déclarant un alias dans la directive using de cette façon: using UrlManager = FrenchCoding.Helpers.UrlManagement;. À la longue, ça devient irritant.
Ceci étant dit, nous trouvions que le nom UrlHelper correspondait bien à la tâche que devait accomplir cette classe utilitaire. Sa raison d’être est d’aider le développeur à récupérer une URL pour une page web donnée.
Le deuxième choix était d’opter pour UrlManager. Cependant, j’avais une très grosse réserve à utiliser ce nom. Ne trouvez-vous pas que le suffixe Manager est utilisé à outrance en développement logiciel? Apparemment, il semble bien que je ne sois pas le seul!
Par contre, les alternatives ne sont pas plus appropriées. Dans une question StackOverflow, les suggestions suivantes sont énumérées:
- Coordinator
- Builder
- Writer
- Reader
- Handler
- Container
- Protocol
- Target
- Converter
- Factory
- Entity
- Bucket
- Builder
- Writer
- Reader
- Handler
- Container
Malgré ces suggestions, l’option que nous préférerions est celle du UrlManager. Il s’agissait d’un moindre mal à mes yeux, car la métaphore avait quand même du sens dans notre contexte d’utilisation.
En bout de compte, pour nous la discussion a été bénéfique car elle a mis de l’emphase sur un aspect important du développement logiciel. C’est-à-dire l’importance à accorder aux noms que l’on donne aux différentes métaphores, méthodes et variables qui sont programmées.
French Coding 
