Archives mensuelles : mars 2015

Les liens de la semaine – Édition #125

Développement

.NET

Technologie

Web

Science et autres

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