Il était une fois des programmeurs voulant nommer une classe

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.

Les liens de la semaine – Édition #124

Développement

.NET

Technologie

Web

Science et autres

Développeurs .NET, êtes vous Lazy?

Je crois qu’il n’y a pas une journée où je ne m’attends pas à être surpris par une technologie que j’utilise. Est-ce que cela vous arrive souvent de ne rien apprendre du tout dans l’équivalent d’une journée? Moi, non. Même que c’est quelque chose qui arrive toujours lorsque je ne m’y attends pas!

Si vous êtes un développeur expérimenté, je suis pratiquement certain que vous avez déjà écrit ce genre de code lorsque vous avez à exposer certaines propriétés d’une classe.

Il s’agit d’une technique appelée du Lazy Initialization ou un property backing field. C’est comme vous voulez, ça revient un peu au même.

La raison d’être de ce code est simple. Vous désirez éviter d’avoir à exécuter le code d’une propriété à chaque fois que vous l’invoquez. Alors, ce que vous devez faire c’est comme dans l’exemple ci-haut. Utiliser un objet qui contiendra la valeur de cette propriété le temps de la vie de l’objet.

Cette technique n’est pas parfaite, car vous devez maintenant penser à une stratégie pour l’invalidation de cette mise en mémoire. Alors, il s’agit d’une technique qui doit vraiment être uniquement appliquée sur des données ayant une petite durée de vie.

Ditez bonjour à Lazy<T>

Depuis .NET 4, Microsoft a ajouté une classe permettant de faire du Lazy Initialization à même le framework. Cela se fait en utilisant la classe Lazy<T>.

Ce que vous voyez ici est le même code que celui précédemment démontré en utilisant Lazy<T>. C’est beaucoup plus évident de déterminer l’intention du code dans cet exemple-ci. De plus, comme je dis souvent, moins de code, moins d’erreurs possibles.

En supplément, Lazy<T> est tread safe par défaut. C’est un argument de plus qui fait pencher la balance un peu plus en sa faveur. N’est-ce pas?

Ressources supplémentaires

Les liens de la semaine – Édition #123

Développement

.NET

Technologie

Web

  • Cette annonce a piqué ma curiosité: Announcing Starfighter. Un du style Capture the flag où vous réalisez vos objectifs en programmant. 
  • Sur le plan personnel, j’ai été touché par ce texte: Before I go

Science et autres

Utiliser scriptcs et C# pour analyser le contenu d’une URL en .NET

Si vous me demandiez de choisir un défaut et de vous en parler, je choisirais certainement ma mémoire. Il y a des gens, comme ma conjointe, qui est capable de souvenir de recettes ou de la liste d’épicerie par coeur.

Moi, c’est le contraire.

Je n’ai pas une très bonne mémoire. Afin de pallier à ceci, je prends des notes et je m’invente des mécanismes pour me souvenir de détails. Après tout, une bonne partie de mon travail réside sur ma capacité à me remémorer ces détails et de mettre en place une solution basée sur ces détails.

Ceci étant dit, je suis très visuel. Comme dirait l’autre: on ne veut pas le savoir, on veut le voir!

Chaque fois que je dois manipuler une URL dans l’un de mes projets, j’ai toujours un trou de mémoire sur quelle propriété à utiliser pour mes fins. Certes, je sais faire la distinction entre Uri.DnsSafeHost et Uri.Scheme. Cependant, j’aime toujours avoir la certitude que ce que j’utilise est bien ce dont j’ai besoin.

La documentation MSDN sur les propriétés de la classe Uri répond au besoin. Ce n’est pas le point. Il s’avère juste que je suis un peu paresseux. Alors, qui dit développeur paresseux dit automatisation possible. C’est ainsi que je suis arrivé avec l’idée d’un script scriptcs qui exposerait les propriétés de la classe Uri pour une URL donnée.

Je suis un génie comme dirait l’autre. En même temps, c’est assez maigre comme concept. Peu importe, je le trouve bien utile!

Le code

Trente lignes en incluant les lignes vides. Enregistrez le contenu sous un nom de fichier ayant l’extension .csx (c’est l’extension de scripts scriptcs).

Exécutez le script en utilisant la commande suivante: uri.csx — http://frenchcoding.com/2015/03/09/les-liens-de-la-semaine-edition-122/ et le tour est joué!

uri

Suivre

Recevez les nouvelles publications par courriel.

Joignez-vous à 366 autres abonnés