mardi 7 août 2012

Visual Studio 2012 RC - première impression.

Je viens juste d'installer Visual Studio 2012 RC qui est sortie le 31 mai dernier (avec donc un peu plus de 2 mois de retard...).

J'aurai pu vous parler des divers évolutions (ce que je ferais surement dans des prochains posts), mais je voulais juste vous donner ma première impression :
Personnellement, je suis un peu déçu sur le look graphique très terne.

Jugez par vous même :

 En haut Visual Studio 2012 RC, et la version précédente Visual Studio 2010.




Je vois bien l'envie de s'orienter vers Metro, mais je trouve finalement que l'interface y perd en lisibilité.
D'un autre côté, j'ai l'impression que plus de choses sont affichés à l'écran grâce à une police et des boutons moins gourmands en place.
Mais, le manque de couleurs détériore la lisibilité.

Je compte l'utiliser pendant quelque temps, je vous ferais d'autres retours sur l'outil, mais n'hésitez pas à donner votre avis.

samedi 4 août 2012

Non duplication de code - Design Patterns - Chaîne de responsabilité

Il arrive souvent que du code soit dupliqué.
Cette pratique est à bannir car à chaque évolution, le développeur est obligé de modifier l'ensemble des copies du code.
La bonne démarche consiste à mettre à disposition le code dupliqué à un seul endroit, et de l'appeler autant de fois que nécessaire.
Ceci arrive souvent avec l'implémentation de la chaîne de responsabilité
La chaîne de responsabilité (ou chain of responsability) est un design pattern.

Vous pouvez trouver une implémentation de ce dernier sur le site dofactory.com.

Ce dernier permet donc de consulter un ensemble d'objets pouvant répondre à une même requête, tout en construisant la chaine d'objets consultés dynamiquement.


 
Chaque objet consulté implémente donc la même interface que la classe Handler. Ces objets sont souvent sollicités de même façon
  • Il teste la requête pour savoir si elle le concerne.
    • Si oui, il exécute sont traitement.
    • Si non, il transmette au suivant. 
Pour illustrer, lorsqu'on vous demande quelque chose soit vous savez et vous traitez, soit vous ne savez pas alors vous transmettez la demande à votre chef. Ce dernier fera de même avec la demande, ainsi de suite jusqu'à trouver la personne compétente pouvant la traiter.
Malheureusement ce schéma (souvent présent), est majoritairement dupliqué dans chaque classe dérivant d'Handler.

Afin d'éviter le copier-coller, sachant que chaque informaticien devrait être payé à la ligne de code qu'il n'écrit pas, j'utilise une classe intermédiaire évitant cette duplication.

En reprenant l'exemple de chez dofactory cela donne  pour la classe intermédiaire :

Et par conséquent les handlers concrets donnent, par exemple pour ConcreteHandler1 :
pour les autres, il suffit de changer le ConcernTest

Évidemment dans l'exemple ici,  l'Action est identique, mais dans une utilisation réelle cette méthode serait spécifique.

Nous avons donc réussi notre objectif, à savoir éviter de dupliquer la méthode HandleRequest.