Another .NET Blog

Je vais aujourd'hui vous présenter le résultat d'un refactoring de masse dans une série de tests unitaires, qui a permis d'accroitre très fortement la lecture des tests, et surtout leur compréhension.

La classe testée a pour but de gérer les mises à jour d'une liste de programmes installés sur un ordinateur. Cette classe est très "high-level" dans la mesure où elle permet d'aller récupérer la liste de toutes les mises à jour de toute une gamme de produits, de savoir pour chaque programme quelles sont les mises à jour à installer, puis bien évidemment de télécharger ces mises à jour et les installer.

Comme vous le voyez, cette classe consiste en beaucoup de sous-tâches, qui vont toutes communiquer avec le monde extérieur (internet notamment, pour l'obtention des mises à jours et leur téléchargement). Dans le but d'obtenir des tests unitaires les plus isolés possibles, j'en suis bien sûr arrivé à décomposer chacune de ces sous-tâches et à les identifier par des interfaces bien distinctes, pour lesquelles je laisse à Ninject le soin de les injecter comme il faut.

Rien que du très classique en somme. Le hic étant que cette classe nécessite du coup l'injection de beaucoup de dépendances (5 !) et que la mise en place des mocks dans chaque test rend le test trop long, et sa relecture difficile.

Voici donc une solution pour éviter ce genre de soucis. Solution qui se base, comme vous allez le constater, sur une hiérarchie de Providers Ninject, et une classe de construction d'un Module, qu'on rendra "Fluent".

Un petit billet pour vous informer, si vous ne l'étiez pas déjà bien sûr, de la disponibilité toute récente de Resharper en beta 2 s'il vous plait!

A télécharger donc d'urgence si vous bossez sous VS2010!

Le souci

J'ai récemment du implémenter le dessin d'une grille (comme dans l'éditeur de Visual Studio par exemple) sur un contrôle de type Panel. Innocemment, mon premier essai a été de m'abonner à l'évènement OnPaint du contrôle, et d'ajouter le code suivant:

private void Foo_Paint(object sender, PaintEventArgs e)
{
    using (Pen pen = new Pen(Color.Gray, 1))
        for (int x = 10; x < e.ClipRectangle.Width; x += 10)
            for (int y = 10; y < e.ClipRectangle.Height; y += 10)
                e.Graphics.DrawRectangle(pen, new Rectangle(new Point(x, y), new Size(1, 1)));
}

Je lance l'application, j'ai bien une grille qui est dessinée. Souci: dès que la form est rafraichie (quand on la redimensionne, ou qu'on change les propriétés d'un de ses contrôles enfants), la grille est redessinée, ce qui entraine de violentes lenteurs de l'affichage, avec du bon gros flickering.

La solution pour éviter ce souci est d'utiliser la technique du double-buffering.

La solution

Nous allons implémenter cette stratégie du double-buffer en créant une nouvelle classe, qui prendra en paramètre le contrôle à utiliser, ce qui nous permettra de réutiliser facilement et à moindre frais le code. L'idée est d'utiliser les classes BufferedGraphicsContext et BufferedGraphics pour dessiner l'arrière-plan du contrôle dans un buffer, et quand le contrôle doit se redessiner, on applique le contenu du buffer directement dans le contrôle. Et c'est donc en évitant le dessin progressif de l'arrière-plan du contrôle que l'on va éviter le scintillement.

Mais voici tout de suite la première version de notre classe:

using System;
using System.Collections.Generic;
using System.Drawing;
using System.Windows.Forms;

namespace Tools.GUI
{
    public class DoubleBuffer : IDisposable
    {
        private readonly Control control;
        private bool dirty;
        private BufferedGraphicsContext bufferedGraphicsContext;
        private BufferedGraphics bufferedGraphics;

        public DoubleBuffer(Control control)
        {
            this.control = control;

            bufferedGraphicsContext = new BufferedGraphicsContext();

            CreateGraphicsBuffer();

            this.control.SizeChanged += control_SizeChanged;
        }

        void control_SizeChanged(object sender, EventArgs e)
        {
            CreateGraphicsBuffer();
        }

        private void CreateGraphicsBuffer()
        {
            if (bufferedGraphics != null)
            {
                bufferedGraphics.Dispose();
                bufferedGraphics = null;
            }

            if (bufferedGraphicsContext == null || control.DisplayRectangle.Width <= 0 || control.DisplayRectangle.Height <= 0)
                return;

            using (Graphics graphics = control.CreateGraphics())
                bufferedGraphics = bufferedGraphicsContext.Allocate(graphics, control.DisplayRectangle);

            Dirty = true;
        }

        private bool Dirty
        {
            get { return dirty; }
            set
            {
                if (!value)
                    return;

                dirty = true;
                control.Invalidate();
            }
        }

        public void Dispose()
        {
            if (bufferedGraphics != null)
            {
                bufferedGraphics.Dispose();
                bufferedGraphics = null;
            }

            if (bufferedGraphicsContext != null)
            {
                bufferedGraphicsContext.Dispose();
                bufferedGraphicsContext = null;
            }
        }
    }
}

On commence par créer une nouvelle instance de la classe BufferedGraphicsContext, puis on crée l'instance de BufferedGraphics grâce à l'appel de la fonction CreateGraphicsBuffer, où l'on commence par supprimer l'instance existante, puis où l'on crée effectivement la nouvelle instance grâce à un appel à la fonction Allocate de BufferedGraphicsContext, qui prend en paramètre le Graphics du contrôle, ainsi que le rectangle correspondant à la surface affichée du contrôle. Vous aurez remarqué que l'on ne crée pas le buffer si le contrôle a une largeur ou une hauteur égale à zéro.

Comme on a un nouveau buffer, on met le flag Dirty à true, qui aura pour conséquence de forcer un ré-affichage du contrôle via l'appel de Invalidate() (dans le setter de Dirty). Dans le constructeur de la classe, on s'abonne également à l'évènement SizeChanged du contrôle, car nous devons toujours avoir un buffer qui ait les mêmes dimensions que le contrôle.

C'est bien beau, mais nous n'affichons toujours rien pour le moment. Nous allons corriger ça de suite, on commençant par nous abonner à l'évènement OnPaint du contrôle, dans le constructeur de la classe:

public DoubleBuffer(Control control)
{
	this.control = control;

	bufferedGraphicsContext = new BufferedGraphicsContext();

	CreateGraphicsBuffer();

	this.control.SizeChanged += control_SizeChanged;
	this.control.Paint += control_Paint;
}

Nous allons ensuite définir la fonction control_Paint:

void control_Paint(object sender, PaintEventArgs e)
{
	if (bufferedGraphics == null)
	{
		Draw(e.Graphics);
		return;
	}

	if (Dirty)
	{
		Dirty = false;
		Draw(bufferedGraphics.Graphics);
	}

	bufferedGraphics.Render(e.Graphics);
}

Le fonctionnement du double buffer se fait ici: si on n'a pas de buffer (par exemple, le contrôle a sa largeur ou sa hauteur qui est nulle) , on va dessiner le contenu de l'arrière-plan du contrôle normalement, en passant à la fonction Draw le Graphics du contrôle, auquel on accède grâce à la propriété Graphics de PaintEventArgs. Si par contre on a un buffer, on commence par regarder l'état du flag Dirty. S'il est à true, c'est que l'on doit redessiner le buffer, ce qui est fait en passant la propriété Graphics de la classe BufferedGraphics. Et pour terminer, on appelle la fonction Render de BufferedGraphics, qui va écrire le contenu du buffer directement dans l'objet Graphics donné en paramètre, c'est à dire dans le Graphics du contrôle, provoquant donc l'affichage du contrôle.

Nous faisons mention dans le code précédent d'une fonction Draw, que voici:

private void Draw(Graphics graphics)
{
	if (control.ClientRectangle.Width <= 0 || control.ClientRectangle.Height <= 0)
		return;

	using (SolidBrush backBrush = new SolidBrush(control.BackColor))
		graphics.FillRectangle(backBrush, control.ClientRectangle);
}

Tout ce que fait cette fonction pour le moment, c'est juste de remplir l'arrière-plan du contrôle avec la couleur définie par la propriété BackColor. Pas très intéressant donc. Il serait bien de pouvoir définir des fonctions à exécuter dans la fonction Draw, afin de personnaliser l'affichage, et de profiter du double buffering mis en place. Nous allons arriver à ça en utilisant une liste d'actions, qui seront exécutées à la fin de la fonction Draw. Les actions étant enregistrées par l'utilisateur de la class DoubleBuffer via une fonction RegisterPaintAction.

Nous allons commencer par ajouter un nouveau membre à notre classe:

private readonly List<Action<Graphics, Rectangle>> paintDelegates = new List<Action<Graphics, Rectangle>>();

Puis nous exécutons la liste des actions dans la fonction Draw:

private void Draw(Graphics graphics)
{
    if (control.ClientRectangle.Width <= 0 || control.ClientRectangle.Height <= 0)
        return;

    using (SolidBrush backBrush = new SolidBrush(control.BackColor))
        graphics.FillRectangle(backBrush, control.DisplayRectangle);

    paintDelegates.ForEach(action => action(graphics, control.DisplayRectangle));
}

Et nous créons les fonctions d'enregistrement et de dés-enregistrement des actions (utile pour par exemple afficher ou pas la grille):

public void RegisterPaintAction(Action paintDelegate)
{
    if (paintDelegate == null)
        return;

    paintDelegates.Add(paintDelegate);

    Dirty = true;
}

public void UnregisterPaintDelegate(Action paintDelegate)
{
    if (paintDelegates.Remove(paintDelegate))
        Dirty = true;
}

On met le flag Dirty à true quand on ajoute une nouvelle action pour forcer un ré-affichage du contrôle immédiat.

Et voilà! Et pour utiliser tout ça, un petit exemple d'affichage de grille dans l'arrière-plan de la form:

using System.Drawing;
using System.Windows.Forms;

namespace WindowsFormsApplication1
{
    public partial class Form1 : Form
    {
        private readonly DoubleBuffer doubleBuffer;
        
        public Form1()
        {
            InitializeComponent();

            doubleBuffer = new DoubleBuffer(this);

            doubleBuffer.RegisterPaintAction((graphics, rectangle) =>
                                                   {
                                                       using (Pen pen = new Pen(Color.Gray, 1))
                                                           for (int x = 10; x < rectangle.Width; x += 10)
                                                               for (int y = 10; y < rectangle.Height; y += 10)
                                                                   graphics.DrawRectangle(pen, new Rectangle(new Point(x, y), new Size(1, 1)));
                                                   });
        }
    }
}

C'est tout pour cette fois ;) N'hésitez pas à me laisser vos impressions ou vos retours sur ce code!

PS: je joins à cet article le code complet de la classe DoubleBuffer.

Je cherchais récemment à détecter grâce à la reflection tous les types d’une assembly qui dérivaient d’un type de base générique, afin d’utiliser une version modifiée de la factory que j’ai déjà présenté sur ce blog. Soit par exemple un type comme celui-ci: class Toto : Base<int> Pour cela, j’ai trouvé sur internet une petite fonction qui fait ça bien comme il faut:

private static bool IsTypeDerivedFromGenericType(Type typeToCheck, Type genericType)
{
	if (typeToCheck == typeof(object))
		return false;
	if (typeToCheck == null)
		return false;
	if (typeToCheck.IsGenericType && typeToCheck.GetGenericTypeDefinition() == genericType)
		return true;
		
	return IsTypeDerivedFromGenericType(typeToCheck.BaseType, genericType);
}

A l’utilisation, on a donc:

Assembly assembly = Assembly.GetExecutingAssembly();

// Loop each type in assembly
foreach (Type type in assembly.GetTypes())
{
	if (type.IsClass && !type.IsAbstract && IsTypeDerivedFromGenericType(type, typeof(GenericManager<>)))
	{
		//...
	}
}

A mettre d’urgence dans votre DLL à tout faire!

J'avais donné dans mon article précédent un lien expliquant comment utiliser plusieurs Expect pour une même fonction.

Il se trouve que j'aurais dû être plus consciencieux dans mon article, puisqu'un test unitaire se devait vraiment d'utiliser cette fonctionnalité très puissante de Moq.

En voici la preuve...

J'ai posté il y a quelques temps un article sur la sérialisation XML où je donnais une astuce pour enlever les attributs xmlns:xsi et xmlns:xsd ajoutés automatiquement par le serializer. Le souci est que si la racine doit contenir un attribut de votre classe, vous êtes roulés, il va disparaître en même temps.

Heureusement il y a une autre méthode, qui est même la méthode officielle. Il suffit de créer une instance de la classe XmlSerializerNamespaces et de passer cette instance dans la fonction Serialize de XmlSerializer.

Démonstration:

XDocument xDoc = new XDocument();

XmlSerializerNamespaces namespaces = new XmlSerializerNamespaces();
namespaces.Add( "", "" );

using (XmlWriter xmlWriter = xDoc.CreateWriter())
    xmlSerializer_.Serialize(xmlWriter, objectToSerialize, namespaces);

Et voilà le travail :)

Have fun!

Petites fonctions sur les dates que j'ai utilisé au boulot qui mettent en avant une fonctionnalité nouvelle de C# 3.0: les extension methods. Au menu:

• Connaitre la semaine d'une date
• Récupérer le lundi d'une semaine
• Récupérer le lundi d'une semaine donnée

Pour concaténer des chaînes de caractères en C#, il existe 3 méthodes:

• l'opérateur += de la classe String
• la fonction String.Concat
• la classe StringBuilder

Vous avez peut-être déjà lu à plusieurs reprises que, concernant les concaténations de chaînes, il valait mieux utiliser StringBuilder. Personnellement, je n'avais jamais vu de benchmarks tendant à prouver cette affirmation (en même temps, j'ai pas vraiment cherché.)

J'ai donc décidé de faire ça moi-même, et voici les résultats, après le break...

Je ne sais pas pourquoi je n'avais jamais pensé à développer une variante du [Design Pattern] [Singleton]. C'est pourtant un des DP que j'utilise le plus souvent...

Bref, c'est maintenant chose faite, et c'est juste après le break

Dans un précédent billet j'expliquais comment sérialiser facilement et à moindre frais en XML avec le framework .NET.

Voici maintenant la même chose, mais en utilisant les objets de LINQ To XML, notamment XElement.