Archive for the 'Qualité du code' Category

Le singleton nul

Julien on mai 27th 2008

Je le dirai honnêtement: je n'aime pas le pattern appelé singleton. Ce pattern était très utile il y a quelques années, avant l'émergence de techniques comme dependency injection (injection de dépendances) ou dependency lookup (recherche de dépendances). Malheureusement pour moi, ce pattern est probablement celui qui est le plus (mal!) utilisé dans le développement logiciel. Je l'admets volontiers, le singleton peut être utile dans de nombreux scénarios, mais sérieusement... pas partout! (Si vous n'avez aucune idée de ce dont je parle, le singleton est un pattern qui permet de s'assurer qu'il n'existera qu'une seule instance d'une classe donnée. Cette instance est créée sur demande, la première fois que la classe est utilisée)

Les principaux problèmes avec les singletons sont évidents:

  • Vous ne contrôlez pas le moment auquel l'instance de la classe est créée. Si vous utilisez beaucoup de singletons dans vos projets, vous n'aurez aucune idée de l'ordre dans lequel les objets sont créés. Ce n'est pas un gros problème pour les petits logiciels, mais c'est plus inquiétant lorsque vous avez quelques centaines de millier de lignes de code...
  • 99% du temps, l'implémentation utilisé pour le singleton nous lie à une classe spécifique. En conséquent, vous serez obligé de refactorisé le singleton ou d'utiliser des framewoks comme TypeMock si vous voulez tester votre code. (Vous pouvez également avoir un singleton qui offrira une point d'accès à la seule et unique instance d'une seconde classe en la castant en une interface. Problème: a moins que cette seconde classe soit aussi un singleton, rien ne garanti qu'il n'existe qu'une seule instance...)
  • Les dépendances ne sont pas évidentes (ce qui peut également être un problème avec l'utilisation du pattern dependency lookup). Si vous avez un type A qui utilise un singleton de type B, rien dans la signature de A ne fera apparaitre la dépendance au grand jour. Par exemple, ce peut être un problème si vous n'êtes pas au courant qu'utiliser A peut provoquer quelques dizaines d'appels à la base de données par l'intermédiaire de B!

Cependant, j'ai récemment découvert un pattern pire que le singleton: je l'appelle le singleton nul ! C'est un concept très simple: le singleton peut échouer à s'instancier si une dépendance (un fichier de config, une base de données, un object distant, etc) n'est pas disponible. Dans ce cas, l'instance retournée par le singleton peut être nul. Voyons un exemple:

  1. class NullSingleton
  2. {
  3. private static NullSingleton _instance;
  4.  
  5.  
  6. public static NullSingleton Instance
  7. {
  8. get
  9. {
  10. if (_instance == null)
  11. {
  12. if (CanAccessMyDependency())
  13. {
  14. _instance = new NullSingleton();
  15. }
  16. }
  17.  
  18. return _instance;
  19. }
  20. }
  21.  
  22. private static bool CanAccessMyDependency()
  23. {
  24. // check if you can connect to the database for instance.
  25. }
  26.  
  27.  
  28. private NullSingleton()
  29. {
  30. }
  31.  
  32. }

Qu'est ce qui est problématique avec cela?

  • Si la dépendance n'est pas disponible, le singleton nul vérifiera à chaque accès le statut de la dépendance. Ce sera très probablement très lent (généralement c'est un appel en dehors du process).
  • A chaque fois que vous accédez à l'instance du singleton, il faut vérifier si la référence n'est pas nulle. Ce qui ajoute un bruit considérable et force des traitements supplémentaires.
  • Enfin, c'est contraire aux attentes usuelles à propos des singletons (c'est à dire que la classe devrait toujours retourner 1 et 1 seule instance, et non pas 0 ou 1 instance). Le comportement n'est donc pas évident, ce qui provoquera des bugs!

Faites vous une faveur: n'utilisez pas un "singleton nul" :-)

Filed in Qualité du code | No responses yet

Pourquoi j’utilise un préfixe pour mes membres privés

Julien on mai 21st 2008

J'utilise un préfixe (A savoir: "_") pour indiquer les membres privés de mes classes. Autrement dit, une de mes classes ressemblera à cela:

  1. public class Car
  2. {
  3. private string _model;
  4. private string _owner;
  5. [...]
  6. }

Différentes notations existent ici et là, notamment "m_". Mais de nombreuses personnes ont aussi choisi de ne simplement pas démarquer les membres privés des variables locales et autres paramètres. Je suis tout à fait conscient que c'est un sujet polémique, et que les avis sont très partagés. J'aimerai toutefois expliquer pourquoi je trouve personnellement qu'il est important d'avoir cette distinction.

En guise de référence, voici ce à quoi pourrait ressembler une classe sans préfixe:

  1. public class Transportation
  2. {
  3. private TransportStatus status;
  4.  
  5. public TransportStatus Status
  6. {
  7. get { return status; }
  8. }
  9.  
  10. public void ChangeTransportStatus(TransportStatus status)
  11. {
  12. this.status= status;
  13. DoSomeStuff();
  14. }
  15. }

Il y a plusieurs problèmes avec cette classe:

  • Utiliser un préfixe permet de se passer du mot clef "this", ce qui réduit le "bruit" dans les sources. En effet, écrire "this.model" revient en quelque sorte à utiliser un préfixe ("this."). Autant utiliser quelque chose de plus court du coup!
  • Qui plus est, l'utilisation de "this" est optionnelle en C#. On se retrouve rapidement avec un mélange des genres ou certains accès sont fait avec "this". et d'autres le sont sans aucun préfixe. Si on ne connait pas bien le code, on est obligé de constamment vérifier si telle variable est privée avec l'intellisense ou en naviguant dans la classe.
  • L'absence de préfixe provoque rapidement des confusions. Par exemple, dans la fonction ChangeTransportStatus, 2 variables ont le même nom: mon paramètre et mon membre privé. Le code étant ici très simple, il est difficile de se tromper. Dans une fonction de 50 lignes, il peut y avoir potentiellement beaucoup plus d'erreurs: il est courant d'utiliser le paramètre à la place du membre...
  • J'ai également une propriété "Status" qui ressemble énormément à mon membre privé "status" dans mon exemple. L'utilisation du mot clef "this" ne règle en rien la confusion potentielle. Sans préfixe il faut donc être très attentif à l'utilisation des majuscules. Sur certaines lettres la distinction est évidente, sur d'autres, elle l'est beaucoup moins! L'expérience montre que sans préfixe, le code d'une classe utilisera plus ou moins aléatoirement la propriété ou le membre privé en fonction de la rigueur et/ou de l'humeur des développeurs. Pour peu que la propriété encapsule un peu de logique, on se retrouve rapidement avec des effets de bord indésirable.
  • Enfin, et je vous accorde que c'est un argument très discutable mais les nouveaux outils de Microsoft génère le code avec des préfixes (voir Linq to Sql par exemple). Si eux le font, c'est peut être qu'il y a du bon ;-).

Alors, prêt à utiliser un préfixe? :-)

Filed in Qualité du code,Trucs et Astuces | One response so far

Les nombres magiques

Julien on avr 10th 2008

Le code suivant est familier? rien de vous choque?

  1. persistAtIteration = 25000/iterationDurationInMilliseconds;

Si oui, vous êtes en flagrant délit d'utilisation d'un "nombre magique" :), c'est à dire un nombre sorti de nulle part sans aucune explication. Dans le cas ci-dessus, le but de la ligne de code est apparemment de savoir à quelle itération le programme doit réaliser une opération de persistance. Le code est simple et les 2 variables ont des noms plutôt expressifs. Mais la ligne contient aussi le nombre "25000" qui:
- Ne véhicule aucun sens.
- Ne peut pas être réutilisé à travers la classe
- Ne peux pas être modifié simplement (il est "masqué" au milieu du code et à moins de connaitre la valeur exacte, on ne peut pas la chercher simplement)

Modifions légèrement le code par le suivant:

  1. persistAtIteration = persistEachMilliseconds/iterationDurationInMilliseconds;

Désormais, la signification de la ligne est devenu évidente. persistEachMilliseconds indique que l'on veut faire l'opération de persistance toutes les X millisecondes. On le divise par la durée de l'itération pour savoir a quelle itération l'opération doit être réalisée. Le code est devenu bien plus clair!

A noter également que l'utilisation des nombres 0, 1 et -1 est toléré sans qu'il y ait besoin de passer par une variable intermédiaire. C'est notamment vrai pour les boucles for par exemple. Cela peut aussi être le cas d'autres nombres comme dans l'expression suivante qui test si i est un nombre pair: if(i % 2 == 0). C'est donc au programmeur de faire la part des choses.

La littérature sur les nombres magique est très vaste et le sujet a été couvert des centaines de fois. Il n'y clairement a rien de nouveau! Pourtant, chaque projet contient sont lot de nombres magiques, d'où l'écriture de ce billet!

Remarque:
Lorsque vous exprimez des durées, je vous conseille de systématiquement ajouter l'unité au nom de la variable. Soit xxxInSeconds, xxxInMinutes, xxxInDays, etc. Sans cela, il sera nécessaire de vérifier où la variable est utilisé pour savoir quelle est l'unité requise.

Filed in Qualité du code | No responses yet