Après de bons et loyaux services avec wordpress.com, je lève mon chapeau et déménage, un peu comme d’un appartement à une maison! La nouvelle addresse de mon blogue, la seule à être tenue à jour, sera la suivante: http://blog.christianrondeau.net. Cette acquisition me permettra de rendre disponible des exemples de code, des outils gratuits et toute un éventail d’opportunités! S’il vous plaît, mettez à jour vos favoris, et continuez à me rendre visite dans mon nouveau “chez moi”!

Cliquez ici pour être redirigé vers christianrondeau.net

Combien de fois par jour répétez-vous les mêmes actions? Copier des fichiers, vous authentifier chaque fois que vous compilez, effacer des fichiers temporaires, copier-coller des valeurs… probablement plus souvent que vous ne le croyez. Plus souvent on recommence une même activité, plus elle devient naturelle, automatique, et moins on se rend compte du temps qu’on passe à la faire. Résultat, votre temps “productif” est réduit, au profit d’actions démotivantes et répétitives. De plus, votre concentration est constamment compromise. Il existe pourtant un grand nombre d’outils prévus pour accélérer votre travail, prêts à être utilisés. Surtout, vous êtes en mesure de créer vos propres outils, plus adaptés que tout ce que vous pourriez trouver ailleurs. C’est une tâche plaisante et motivante qui optimisera votre temps, minimisera les perturbations et réduira les risques d’erreurs.

Lisez la suite de cet article sur notre nouveau site, christianrondeau.net

Suite à une épuisante journée de travail, vous entrez chez vous, éreinté. Le simple grincement de la porte vous donne l’impression que quelques neurones de plus viennent de lâcher prise, et errent désormais librement dans la masse informe qui compose votre restant de cerveau. C’est en vous affalant sur votre délicieux divan qu’un autre groupe d’employés de votre cortex décide de déserter suite à la cinglante sonnerie de votre téléphone:
- Hey! C’est Untel! (quels parents grossiers appellent leur enfant comme ça?) Je voulais juste t’inviter à souper demain, je vais faire de la lasagne! Oh, et en passant, bon show!
Le souvenir vous frappe comme une requête SQL passée en texte pur dans l’URL; vous avez un spectacle ce soir! Et l’artiste en représentation est justement le préféré d’Untel. Vous êtes mort de fatigue, et décidez donc de ne plus y aller, et de vendre vos billets.
- Bah, dites-vous en soupirant, je suis complètement à terre. Veux-tu les billets?

Lisez la suite de cet article sur notre nouveau domaine, christianrondeau.net

Dernièrement je me suis rendu compte que je lisais d’excellents livres, mais que je ne partageais pas mes découvertes. Empressé de briser cette image d’égoïsme qui me hante, me voici qui en partage quelques uns avec vous!

Lisez cet article sur christianrondeau.net

Il y a de cela quelques mois, je naviguais sur un petit site Flash qui se vantait de pouvoir deviner mes pensées. Assoiffé de mystères à élucider, me voilà qui pense à un nombre, suis les instructions et surprise! Le symbole associé au nombre auquel j’ai pensé est affiché, auréolé d’étoiles.

Lisez cet article sur christianrondeau.net

Première pensée: Ils devinent avec les mouvements des comportements de ma souris.
Mais je continue à réfléchir, et après quelques microsecondes je ris de moi-même. Je recommence donc l’exercice, sans bouger la souris, et comme je m’y attendais ça fonctionne quand même.

Le truc est simple; il fallait choisir un chiffre entre zéro et cent. Une table à droite montrait des symboles à côté de chaque nombre. Il fallait additionner les deux chiffres du nombre, et soustraire ce résultat au nombre choisi. Par exemple, si on prend 75: 7+5=12, 75-12=63. Mais reprenons le calcul avec un autre chiffre, 72: 7+2=9, 72-9=63. Ah ha! On se rend compte que peu importe le chiffre qu’on choisit, ce sont toujours les mêmes quelques résultats qui reviennent. Il s’agit simplement de mettre le tout en forme, en mettant des symboles différents à chaque fois, tant que les mêmes nombres (63, 72, 81…) donnés aient le même symbole.

Après avoir envoyé ce petit truc à quelques amis, j’ai été étonné du retour. Première réponse que je reçois par messagerie instantanée: “Facile, ça détecte le mouvement de la souris.”

Ces gens savaient pertinemment que ce n’était pas le cas. Et s’ils doutaient, valider leurs doutes ne leur aurait pris qu’une seconde. Mais ce n’est pas ce qu’ils ont fait. Alors me voilà qui réfléchis. Pourquoi ce comportement? Il ne s’agit pas que de paresse. Il s’agit de comment nous traitons les acquis.

J’ai mes théories. Chaque jour des centaines de faits viennent à notre attention. Nous ne doutons pas de la justesse de notre perception de ceux-ci à chaque fois, c’est un comportement qui me semble tout à fait normal… lorsque nous n’avons pas à prendre une décision basée sur ces acquis. Si on fait le parallèle avec la programmation, combien de fois on appelle une méthode qu’on ne connaît pas en ne se basant que sur sa signature? Qu’on corrige un bogue avant même d’essayer de le reproduire? Un classique qui me hante personnellement est lorsqu’on m’explique quelque chose et qu’une conception logicielle se dessine dans ma tête. Lorsque des informations viennent la contredire, plutôt que de simplement l’ajouter à ma compréhension du problème, j’ajuste instinctivement ma première idée en conservant ses fondements. Éventuellement celle-ci n’est plus du tout adaptée au problème, mais je suis quand même convaincu qu’elle l’est.

Mais que faire? Peut-on se débarrasser de ce problème?

Je ne crois pas, non. Mais tout espoir n’est pas perdu! On peut certainement alléger les effets de ce réflexe naturel. Je ne suis pas psychologue, mais j’ai développé quelques trucs que vous pourrez mettre en pratique lorsque vous êtes dans une situation où une solution piétinne la problématique encore immature.

Première étape, définir les moments où les préconceptions causent problème. Ils ont un point en commun; ils commencent par une écoute ou une lecture d’un problème, font fait germer des idées dans votre esprit pendant un échange qui dure aux moins quelques minutes et se terminent par une responsabilité partielle ou complète de votre part pour revenir avec une solution.

Deuxième étape, identifier les préconceptions elles-mêmes. Si on y porte attention, c’est assez facile. Dès que vous avez une conception de la solution en tête avant que la problématique soit complète, vous prenez quelque chose pour acquis.

Troisième étape, se débarrasser du fardeau de l’idée. J’ai personnellement une mauvaise tendance à croire qu’une bonne idée ne doit pas se perdre, mais pensez-y; si la description du problème a donné naissance à un concept, pourquoi prenons nous tout le mérite? Après tout, sans problèmes il n’y aurait pas de vos solutions géniales! Bref, ayez confiance en vos aptitudes et ne vous accrochez pas aux bonnes idées. Il est bon de les noter, mais oubliez les détails. Liez les toujours au problème qui vous a inspiré. Si vous n’arrivez toujours pas à vous débarrasser de l’idée, qu’elle pousse malgré vous, demandez à vos interlocuteurs de faire une pause. Prenez quelques secondes pour y penser, établissez ensuite les raisons pour lesquelles vous avez eu cette idée. Finalement, validez avec les autres personnes si votre raisonnement est bon. Ne divulguez pas l’idée elle-même, car la discussion aurait de fortes chances de tomber sur l’implémentation, et le but est justement d’éviter cette chute. Par exemple, prenez cette situation:

Jules, l’analyste principal du projet, présente à l’équipe de développement les spécifications du système.

- L’utilisateur pourra donc entrer un numéro, énonce Jules, qui correspondra au code du système ABC. Il est important que l’étiquette liée au code soit affichée lorsqu’il valide le code. Il pourra ensuite continuer à remplir le formulaire.

Marc, un des développeurs de l’équipe, perd immédiatement son attention. Il se rappelle d’un article qu’il a lu au sujet des plug-ins. Mais voilà une occasion en or d’implanter ses connaissances! Son raisonnement va comme suit : De cette manière, si on doit changer le système ABC, ou même ajouter d’autres codes, ça sera facile comme tout! Mais Marc ne se laisse pas avoir, et réfléchis aux raisons qu’il l’ont amené à cette conclusion. Premièrement, un système externe est en jeu. Celui-ci peut changer. Ensuite, il s’agit d’une question ordinaire dans un formulaire qui pourrait très bien contenir d’autres cas où les données requises sont reliées à une logique externe au formulaire lui-même. Il pose donc ces questions:

- J’aimerais avoir des précisions. Il s’agit d’une question ordinaire? Est-ce que le système ABC est sous le contrôle de notre client? Finalement, est-ce qu’on prévoit d’autres cas où on devra communiquer avec un autre système?

Les réponses de Jules pourraient être variées. Peut-être que le système ABC est en réalité la base de données que vous devrez utiliser. Peut-être qu’après avoir appris qu’il s’agit d’un webservice déjà implémenté chez le client, vous ferez simplement une question configurée pour appeler un webservice. Peut-être vous rendrez-vous compte que votre idée s’applique toujours, mais dans tous les cas vous aurez les informations nécessaires pour passer à autre chose.

Quatrième étape, prendre du recul. Revenez de temps à autres sur toutes les informations que vous avez et imaginez-vous repartir de zéro. Révisez vos informations dans le désordre. Contredisez-vous, et obligez-vous à accepter qu’une solution ne sera valide que lorsque vous aurez toute l’information en main.

Mais vous n’aurez jamais toute l’information en main. Bienvenue dans le paradoxe de la conception logicielle!

Cet article est en réalité un courriel répondant à une question sur les bonnes pratiques avec les exceptions. S’il peut être utile à quelqu’un, tant mieux!

Lisez cet article sur christianrondeau.net

Premièrement, l’Exception Management Application Block est surtout fait pour “réagir” et publier les exceptions à l’extérieur du contexte d’exécution du code. Il n’aide donc, selon moi, aucunement à la bonne gestion des erreur à l’intérieur du code.

Généralement on arrive devant un des cas suivants:

• L’exception est lancée dans un contexte transactionnel, dans quel cas le catch et le finally doivent s’assurer de faire le rollback, et laisser la classe appellante faire son rollback aussi. Dans ces cas là on ne veut pas gérer l’exception elle même, seulement s’assurer du bon fonctionnement du code.
• L’exception est lancée à un niveau du stack directement causée par une action de l’utilisateur (par exemple, un paramètre invalide non vérifiable par des validateurs, ou une valeur invalide dans le querystring). Dans ces cas là, on peut simplement gérer l’erreur sur place (afficher une page disant que la page a reçu un paramètre invalide) ou, ma préférence personnelle, laisser l’erreur remonter jusqu’au handler principal (généralement le Main dans une application windows, ou le Global_asax.Application_Error dans les application web).
• L’exception est récupérable (par exemple, le caching plante). Dans ces cas là (plutôt rares), simplement récupérer (et s’assurer qu’il n’est pas possible d’éviter qu’il y aie une exception en remplaçant le code fautif par une vérification des paramètres! Les exceptions ne devraient jamais faire partie intégrante d’un flow “valide” du code) et publier l’erreur.

J’ai toujours créé un assemblage “partagé” contenant les exceptions, les fonctions de logging, etc. par le passé. Je créais toujours des exceptions héritées de ApplicationException (du genre MyProjectException), de laquelle toutes mes exceptions précises héritaient. Avec le temps j’ai réalisé que ça ne me servait strictement à rien. Tant que le message d’exception est clair, et qu’il n’y a pas de besoin de catcher un type précis, une ApplicationException ordinaire fait le travail.

Personnellement je ne suis pas un fanatique de l’Application Block de gestion d’exception. C’est pratique, mais généralement un simple logging au niveau le plus haut de l’architecture fait amplement le travail. (Ça veut pas dire de pas l’utiliser, seulement que je ne donnerais pas de points pour ça dans une architecture). Je ne fais des throws (incluant l’exception initiale) que lorsque de l’information supplémentaire est disponible, sinon je la laisse passer. Exemple:

public bool VerifyCompatibility( Computer c, Version v )
{
–if( c == null )
—-throw new ApplicationException( “Computer parameter must not be null” );

–…
}

public void RegisterComputer( int computerId )
{
–try
–{
—-if( VerifyCompatibility(
——ComputerRegistry.Computer[computerId],
——Versions.CurrentVersion )
——)
——…
–}
–catch( Exception exc )
–{
—-throw new Exception( “Could not register computer ” + computerId, exc );
–}
}

Dans ce cas précédent, si on avait pas encapsulé l’exception, il aurait été très difficile de retracer le cas fautif. Tandis que maintenant on a les exceptions:

[Computer parameter must not be null]
[Could not register computer 689]

L’information, ajoutée à l’URL, l’utilisateur en cours, les informations du navigateur client et le stack trace est suffisante pour reproduire l’erreur et la régler au niveau où il convient. Bref, les exceptions doivent être complémentaires, et servir à:

- Faire faillir le code le plus vite et facilement possible pour détecter les bogues tôt dans le développement
- Avoir l’information la plus concise et complète possible pour reproduire les erreurs facilement.

En bref, les exceptions ne devraient servir à rien d’autre qu’à déboguer et logger. Si vous jugez pertinent de créer une exception spéciale qui contient plus d’information (comme le niveau de gravité de l’erreur ou un message à afficher au client), amusez vous, mais rappellez-vous que généralement on ne log et n’utilise que le message et le stack trace d’une exception.

Une chose importante: une exception ne doit en aucun cas être affichée à l’utilisateur, directement ou indirectement, ni servir à générer un message utilisateur. Si une exception représente un paramètre invalide (disons une lettre dans un TextBox qui devrait contenir un chiffre), c’est effectivement une erreur du programme, et non pas de l’utilisateur. Pourquoi? Une validation de l’entrée de l’utilisateur aurait dû avoir lieu. Par exemple, un achat avec un numéro de carte de crédit invalide qui lance une erreur est un problème majeur, car il y aurait dû y avoir un ValidateCreditCardNumber avant, ou la méthode pourrait retourner un enum du statut de la commande.

À vous de juger! Mon mentra est: léger et complet, et ne jamais laisser passer un “Object not set to an instance of an object”! Jamais!

Une grande question, difficile à répondre; dans quelle langue doit-on déclarer ses variables, méthodes et classes? Dans quelle langue devrait-on écrire ses commentaires?La syntaxe

Premièrement, il faut noter que je suis un francophone aguerri, prêt à bondir pour défendre sa langue. Mais, car il y a un mais, un problème survient; lorsqu’on développe une application, on utilise un langage de programmation. Ce langage est en quelque sorte une langue à part, un sous-ensemble de l’anglais. Sa structure et ses mots correspondent à l’anglais. Quels sont les impacts? Une lecture naturelle.

Lisez cet article sur christianrondeau.net

Par exemple:

if( serverConnection.IsOpened )
{
—Close( serverConnection );
}

on peut facilement lire, vous me pardonnerez l’expression, en changeant notre mode lecture pour l’anglais. En effet, la lecture prend tout son sens:

If the server connection is opened, close the server connection.

Si on utilise la syntaxe francophone, on se retrouve avec:

Si la connection serveur est ouverte, fermer la connection serveur.

La lecture

Maintenant, prenons pour acquis que nous travaillons avec un framework. Celui-ci contient déjà son lot de phrases partielles (opérations) et de noms (types et propriétés). Le mélange est quelque fois dur à avaler:

foreach( Courriel courriel in listeDeCourriels.ToArray( typeof(Courriel) ) )
—if( courriel is CourrielPerdu )
——listeDeCourriels.Remove( courrielPerdu );

Le glossaire

On doit aussi prendre en compte les termes utilisés tout au long du projet. Prenez l’exemple suivant:

//La connection à la base de données utilise la chaîne de connection de la composante de configuration native.
SqlConnection conn = new SqlConnection();
conn.ConnectionString = ConfigurationSettings.AppSettings[CléChaineDeConfiguration];

Premièrement, il est clair que le cerveau n’associera pas instinctivement les termes à leur description. Il faut lire l’un, et traduire l’autre. Ceci ralentit substanciellement la lecture du code – quoique je n’ai aucune donnée pour appuyer mon point.. il me faudra acquérir une copie de Code Switching in Conversation, de Peter Auer.

Ensuite, le développeur se retrouve avec une tâche supplémentaire: traduire le framework.

Et s’il veut hériter de TextEditor pour intégrer le HTML, comment devra-t-il l’appeller? HtmlEditor? EditeurHtml?

Conclusion

Le mélange de plusieurs langues cause de nombreux problèmes légers qui, je crois, peuvent être mitigés en utilisant un jargon unifié.

Je considère par contre qu’un jargon francophone doit être édifié, et qu’une discussion technique puisse se faire dans notre langue natale de manière naturelle et transparente.

Qu’en pensez-vous?

Un petit article sur un détail important mais qui, je crois, n’a pas été beaucoup discuté; le nombre d’appels sur des objets dans une ligne de code.

Prenons par exemple la ligne de code suivante, ou employe est un paramètre de méthode:

int assignements = employe.GetHoraire().GetAssigments(this.jourEnCours).Length;

Elle peut paraître exagérée pour certains, mais elle représente plusieurs cas que j’ai vu et que j’ai fait. Beaucoup auront prévu le coup; en production l’erreur suivante est lancée:

Object reference not set to an instance of an object.

Lisez cet article sur christianrondeau.net

*musique dramatique* béât devant son courriel d’erreur (car bien sûr le programmeur fautif s’est sagement envoyé le stack trace ainsi que le nom de l’utilisateur connecté, la page visualisée et la date). On a deux cas possible:

1) Le code était en mode Release

Étendu sur une ligne ou sur huit, on a pas la ligne de code de toute façon, alors les bonnes pratiques font “ding”: toujours vérifier si les valeurs attendues sont nulles! Quoique ce n’est pas toujours facile lorsqu’on va chercher un sous-sous-sous-sous objet. Morale: éviter de traîner de trop grosses structures (pas toujours facile).

2) Le code était en mode Debug (oublions que c’était en production)

C’est la que cet article dit ce qu’il a à dire: on a la ligne de code (après tout on s’attend à avoir des bogues, sinon on ne serait pas en mode debug) et on est prêts à… oh non. On a aucune idée de la variable qui est nulle! On a plusieurs choix ici.

- De l’instrumentation manuelle (peut-être fastidieux!)
- Des logiciels d’instrumentation automatique (tels qu’AVIcode, que je n’ai pas encore eu l’occasion d’essayer)
- Vérifier les valeurs nulles au début (bonne pratique!)
- Décomposer les appels complexes.

Ce dernier est une pratique simple et efficace. Pourquoi?

- Plus facile de faire “Next” en mode débug et suivre le monceau de code
- On a immédiatement la ligne de code dans le stack trace, et on sait automatiquement quel objet était nul
- Plus facilement lisible
- Possibilité d’insérer des conditions ou des appels supplémentaires sans avoir à décomposer le code
- On visualise plus facilement et rapidement les types auxquels on a affaire. Ça force aussi l’utilisation du “using”. De cette manière, on peut plus facilement voir quels sont les modules réellements impliqués dans une classe.
- Le nombre de lignes de code est plus représentatif de l’application

Si on reprend l’exemple de tout à l’heure, on a:

Horaire h = employe.GetHoraire();
Assignement[] as = h.GetAssignements(this.jourEnCours);
int assignements = ((as==null)?0:as.Length);

Il devient aisé d’insérer les vérifications d’objets nuls à mesure, et le tout est plus lisible.

Les cons pouvant survenir sont surtout la performance (une référence est créée et conservée), quoique selon moi complètement transparente (à vérifier avec un profiler), et la longueur du code. Il s’agira ici de simplifier le code si on voir qu’on doit décomposer des monstres!

En bref, décomposer les appels imbriqués est selon moi une pratique simple, facile à faire et très efficace. Utilisez là!

Beaucoup de gens ont travaillé avec des composites. Ils s’avèrent en effet utiles pour déterminer des règles imbriquées, des catégories à plusieurs niveaux, des menus récursifs etc. Il est par contre difficile de les afficher en ASP.NET sans transformer le code en amas monstrueux de conditions. Voici donc l’approche qui, selon mon humble opinion, s’est avérée la plus simple et la plus facile à maintenir.

1) Définir notre composite

La première étape consiste à vérifier si le composite en est bien un. En effet, une erreur que je vois souvent est de considérer que l’extrémité du composite est nécessairement l’élément qui n’est plus une collection. Hors, dans plusieurs cas, la dernière collection contient d’autres types qui n’héritent pas du type abstrait, ou le font “de force”. Un exemple simple serait le cas suivant:

J’ai des boîtes de crayons, de différentes tailles. Ces boîtes, faites pour la revente, peuvent être empaquetés dans des boîtes pour les magasins, qui à leur tour peuvent être empaquetés pour le transport, et ainsi de suite. L’implémentation erronée dont je parle ressemblerait à ceci:

classe Boîte héritant de BoîteStratégie
  collection BoîtesImbriquées de type BoîteStratégie

classe Crayon héritant de BoîteStratégie

Le type Crayon ne partage aucune logique avec la boîte, pourtant beaucoup auront tendance à penser que le Crayon est l’extrémité de la structure, résultant en de grandes difficultés à filtrer les types à l’affichage. Une meilleure structure serait la suivante:

classe Boîte héritant de BoîteStratégie
  collection BoîtesImbriquées de type BoîteStratégie

classe BoîteDeCrayons héritant de BoîteStratégie
  collection Crayons de type Crayon

Le type Crayon ne partage aucune logique avec la boîte, pourtant beaucoup auront tendance à penser que le Crayon est l’extrémité de la structure, résultant en de grandes difficultés à filtrer les types à l’affichage. Une meilleure structure serait la suivante:

classe Boîte héritant de BoîteStratégie
  collection BoîtesImbriquées de type BoîteStratégie

classe BoîteDeCrayons héritant de BoîteStratégie
  collection Crayons de type Crayon

Dans le premier cas on aurait été obligé, dans le contrôle affichant une catégorie, de supporter tous les types d’éléments.

Dans le deuxième cas, on a un contrôle qui ne fait qu’afficher (encadrer) une catégorie, et le deuxième contrôle gère l’affichage d’une liste de crayons. On peut ainsi afficher une structure d’arbre contenant des couleurs sur l’horizontale sans complexifier la structure.

2) Définir l’affichage désiré

Il n’y a pas de “silver bullets”, Brooks a raison, et cela s’applique à tous les niveaux. Il existe beaucoup de méthodes pour afficher des composites, et certains affichages très complexes, ou non-standards, peuvent demander une approche complètement différente. Je ne présenterai ici la solution la plus commune selon moi.

Pour donner une idée des différents affichages possible, voici quelques exemples:

1. Une liste “flattened” des items du composite
2. Une liste semblable à une table des matières
3. Un arbre semblable à la TOC d’une aide en ligne
4. Un arbre dont les nodes sont des titres et les feuilles sont des fiches
5. Un arbre chargé sur demande avec AJAX (librairie pour C#)
   etc.

Pour la solution à la présentation 1, un simple repeater fait l’affaire, couplé à une méthode récursive comme un visiteur ajoutant chaque objet à une collection ordonnée.

La solution du 5 serait (mais là il ne s’agit que d’une opinion) mieux implémentée en contrôle pur qu’en UserControl.

Toutes les autres solution sont implantables avec la solution proposée.

3) Implémenter les contrôles

Nous aurons besoin d’un minimum de deux contrôles (qu’il faudra évidemment renommer selon le cas précis d’implémentation):

• Un UserControl pour afficher le composite (pour afficher Boîte). Nommons-le CompositeView.ascx et faisons-le hériter de IStrategyView.
• Un UserControl pour afficher les extrémités (pour afficher BoîteDeCrayons). Nommons-le LeafView.ascx et faisons-le hériter de IStrategyView.
• Une interface IStrategyView n’affichant qu’une propriété lecture/écriture. Nommons-la IStrategyView.DisplayedStrategy.
• Plutôt que Boîte, Définissions les abstractions IStrategy représentant la classe abstraite dont hérite le composite, et Composite, assez auto-explicatif.

3.1) CompositeView.ascx

Ce contrôle ne contiendra que le conteneur parent. Un cas typique serait l’étiquette du composite, une forme d’indentation visuelle et un Repeater contenant les enfants.

CategoryName

<blockquote>
  <asp:repeater
    id=”ChildrenRepeater”
    datasource=”<%#((CategoryComposite)DisplayedCategory).Children%>”
    Runat=”server”
    OnItemCreated=”ChildrenRepeater_ItemCreated”>
    <itemtemplate />
  </asp:repeater>
 </blockquote>

Le code de cet affichage de composite contiendra principalement une méthode chargeant le bon contrôle-enfant dynamiquement:

protected void ChildrenRepeater_ItemCreated(…)
{
  if(
      e.Item.ItemType == ListItemType.Item ||
      e.Item.ItemType == ListItemType.AlternatingItem
     )
  {
    Control ctl = LoadControl(
      e.Item.DataItem.GetType().Name + “View.ascx”
      );

    ((ICompositeView)ctl).DisplayedCategory
      = (IStrategy)e.Item.DataItem;

    e.Item.Controls.Add(ctl);
  }
} 

Voilà, notre récursivité est prête. Il ne reste plus qu’à implémenter les feuilles.

3.2) LeafView.ascx

Ce contrôle est utilisable à toutes les saveurs. La seule restriction est d’implémenter l’interface IStrategyView et que le contrôle puisse s’intégrer au design du CompositeView.ascx. Un exemple relatif aux boîtes de crayon serait un Repeater qui afficherait une table à trois lignes dont la partie du haut et du bas seraient des images de mines et d’effaces de crayon, tandis que le centre serait rempli avec la couleur de Crayon.Couleur. Le Repeater itérerait en créant des colonnes pour chaque crayon.

Conclusion

Cette approche est, jusqu’ici, le juste milieux entre des approches simples mais peu flexibles, et d’autres très complexes à maintenir. Elle permet aussi d’être modifiée pour afficher différents types de contrôles selon des conditions variées. Le design est centralisé et ne contient aucune condition d’affichage, le rendant simple à maintenir. Elle n’a rien d’extraordinaire, pourtant j’aurai vu et fait beaucoup d’implémentations très originales pour afficher des composites, pas toujours très efficaces je l’avoue.