Les Hooks ou l'extensibilité d'un objet / programme

Dans un précédent billet, j'exposais un cas particulier à traiter sur certaines pages.

Rappel des faits : un contrôle se charge d'aller chercher un flux RSS ou Atom afin d'afficher chaque élément sur une page Web afin d'obtenir à peu près ce résultat :

Les pages du site sont pour la plupart en UTF-8 (ou du moins le devraient), mais certaines (en raison d'un lourd existant), présentent un cas particulier : elles sont encodées en ISO-8859-1 (voire Windows-1252). La conséquence de cet encodage est un défaut d'affichage pour certains caractères issus du flux et encodés en UTF; ce qui donne ce mauvais résultat (remarquez les ?) :

Solution simple et rapide qui vient à l'esprit : convertir les caractères dans leur équivalent ISO dans le contrôle.

Cette solution ne satisfait pas le cas commun des pages en UTF, il faudra ajouter au contrôle une propriété qui précisera si on veut ou non la conversion en ISO le cas échéant. Ce qui est gênant dans cette rustine, c'est que pour traiter un cas particulier, nous sommes obligés d'apposer une propriété au contrôle, et ce potentiellement pour chaque cas spécifique : à force, on va se retrouver à gérer pleins de cas, donc faire pleins de si(propriete_A) alors faire traitement particulier, ce qui n'est pas forcément le rôle du contrôle (qui devrait traiter le cas général uniquement), la solution n'est pas élégante dira-t-on.

Alors comment rendre extensible mon contrôle sans pour autant qu'il devienne illisible : en donnant la possibilité d'appliquer un hook au moment de l'affichage des éléments du flux.

Alors, qu'est qu' un hook, selon cette définition :

(...) fonction permettant une plus grande facilité dans l'adjonction de fonctionnalités nouvelles au programme

C'est juste ce qu'il nous faut, une technique simple à mettre en oeuvre, et qui conserve le principe du ouvert-fermé en conception objet.

En C#, les événements (voire les délégués associés) répondent notamment à ce besoin : autoriser des clients à s'enregistrer sur un objet afin de déclencher des méthodes pour du traitement spécifique. Les événements pourraient aussi être utilisés pour établir une communication inter-objets : qu'un objet serveur puisse donner de l'information à ses clients abonnés, par exemple, sur l'état d'avancement d'un processus.

Notre classe contrôle offre alors un événement sur lequel s'abonner, le contrôle déclenchera alors l'événement au moment opportun, ici lors de l'affichage des données, et une méthode pour déclencher manuellement l'événement si besoin de la part des clients de l'objet :

event EventHandler Displaying;
void OnDisplaying(Item it, EventArgs arg);

Par défaut, on utilise EvenHandler, car peu d'informations sont à échanger, on pourrait bien entendu implémenter une classe qui dérive d'EventHandler si l'on souhaitait y mettre plus d'informations non directement liées à l'objet à traiter (ici l'élément du flux, la classe Item) : un état, un contexte d'utilisation, ...

Il suffit alors de s'abonner à l'événement du contrôle à partir de ma page aspx, et de mettre le traitement ad-hoc souhaité, ici, la conversion des caractères :

private void InitializeComponent()
{
       moncontrole.Displaying += new EventHandler(_default_Displaying);
}
void _default_Displaying(object sender, EventArgs e)
 {
            if (sender != null &
                sender is Item)
            {
                ((Item)sender).Title = UTFtoWin1252(((Item)sender).Title);
                ((Item)sender).Description = UTFtoWin1252(((Item)sender).Description);
            }
}

dans le contrôle on déclenchera l'événement à chaque affichage d'une élément du flux, dans le CodeFile/CodeBehind du contrôle :

// on expose la possibilité d'un branchement à l'événément Displaying
public event EventHandler Displaying;
// pour le déclenchement manuel de l'événément
public void OnDisplaying(Item it, EventArgs arg)
{
      // si branchement alors on exécute la méthode cliente attachée
      if (Displaying != null)
             Displaying(it, arg);
}

et dans l'ascx du contrôle, on pourrait avoir dans le repeater chargé d'afficher les éléments du flux, le déclenchement de l'événement :

<script language="C#" runat="server">
private Item _doDisplaying(Item it)
{
        // déclenchement manuel de l'événement
        OnDisplaying(it, new EventArgs());        
        return it;
}
</script>
<div id="flux">
<asp:Repeater ID="rpRss" runat="server">
    <HeaderTemplate><ul class="item"></HeaderTemplate>
    <ItemTemplate>       
    <li class="itemelt">
            <p>
              <span class="itemtitle">
              <a class="itemlink"" 
              href="<%# _doDisplaying((Item)Container.DataItem).Link %>"><%# _doDisplaying((Item)Container.DataItem).Title)%></a>
              </span>
              <span class="itemdate">(<%# string.Format("{0:dd/MM/yyyy}", _doDisplaying((Item)Container.DataItem).DatePublication)%>)</span>
            </p>
            <p>
            <span class="itemdescription">
                <%# _doDisplaying((Item)Container.DataItem).Description)%>
            </span>
            </p>   
    </li>   
    </ItemTemplate>
    <FooterTemplate></ul></FooterTemplate>
</asp:Repeater>
</div>

Les avantages de cette solution :

• le contrôle n'est pas pollué de cas particuliers à traiter, on rend la responsabilité au(x) client(s) du contrôle de traiter le cas.
• va avec le 1er point, on évite pleins de if et donc plein de code à maintenir
• on étend le comportement de la classe du contrôle sans la modifier
• on peut décider de créer autant de hooks que l'on souhaite - on pourrait imaginer par exemple, un hook avant d'aller chercher le flux, après recherche du flux, etc...

Inconvénients :

• les clients doivent connaitre un minimum quand est-ce que le hook sera déclenché, doit donc être documenté
• coder des hooks inappopriés ou inutiles (en faire trop sans que cela serve forcément)

En génie logiciel, le plus difficile bien souvent c'est la maintenabilité du système, quelques bonnes pratiques permettent d'en réduire (un peu) la difficulté de la réaliser, encore faut-il y penser