Délégation d'implémentation d'interface: réponse au Quizz

Tout d'abord, toute mon estime à Tétranos pour sa réponse à la question bonus.

En effet, je tentais de résoudre la délégation d'implémentation d'interface...mais qu'est-ce donc ?

En C#, si vous voulez implémenter une interface dans une classe quelconque, vous êtes bons pour implémenter tout ce qu'elle définit.

Parfois, la classe en question aggrège une instance interne qui implémente cette interface et il est alors fort tentant de déléguer l'implémentation de notre interface à cet objet.

Hors en C#, aucune syntaxe n'existe pour cela.

Le framework nous montre à plusieurs endroits qu'il est possible de mettre facilement en place un pattern qui simule ce comportement.

Prenons l'interface IList. Elle hérite de ICollection, qui hérite de IEnumerable. Si vous voulez implémenter IList vous vous retrouvez avec environ une vingtaine de méthodes à implémenter.
Assez laborieux et on aimerait dans de nombreux cas déléguer ça à une classe commune générique et paramétrable plutôt que de tout réimplémenter à chaque fois.

Pour cette interface précise, le framework .Net apporte une autre interface qui est IListSource. Cette interface définit tout simplement une méthode "IList GetList()". Dans cette méthode, nous pouvons renvoyer n'importe quelle implémentation de IList.

Attention ce n'est pas suffisant. En effet, implémenter IListSource ne vous fait pas implémenter IList. Cependant, le pattern définit que lorsque les codes appelants IList (comme dans le databinding des winforms ou de WPF), ne trouvent pas IList implémenté dans leur cible, alors ils doivent tester IListSource.

C'est en effet grâce à ce travail "d'équipe" que nous arrivons à substituer la délégation d'implémentation d'interface dans le framework .Net.

Un autre très bon exemple: IEnumerable face à IEnumerator.

A bientôt pour un prochain Quizz,

Mitsu