Voir le flux RSS

François DORIN

[Actualité] C# : Implémentation explicite des interfaces - Partie 4

Note : 2 votes pour une moyenne de 3,00.
par , 24/08/2018 à 19h50 (840 Affichages)
Ce billet s'inscrit dans une série de billets autour de l'implémentation explicite des interfaces en C#.

Dans le premier billet, nous avons vu qu'il existe deux manières d'implémenter une interface en C#. De manière implicite (la voie "classique") et de manière explicite. Le billet était illustré par un exemple d'utilisation, avec la "surcharge" d'une méthode en modifiant uniquement son type de retour.

Dans le second billet, nous avons abordé un autre de ces cas d'usage : le masquage d'une méthode.

Dans le troisième billet, nous avons étudié une autre utilisation possible : implémenter des interfaces définissant les mêmes méthodes, mais avec des sémantiques différentes.

Dans ce quatrième billet, nous allons aborder les propriétés et les événements.

Nom : logo-csharp.png
Affichages : 2082
Taille : 50,9 Ko

Membres d'une interface
Au cours des précédents billets, nous avons abordé uniquement l'implémentation explicite de méthodes spécifiées par une interface. Mais une interface, ce n'est pas uniquement des méthodes, c'est aussi des propriétés et des événements. Nous allons donc voir comment implémenter explicitement cela.

Les propriétés

Comme il s'agit principalement d'un aspect syntaxique, commençons directement par un exemple de code :
Code C# : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8
9
10
    public interface IMonInterface
    {
        string UnePropriete { get; set; }
    }
 
    public class InterfaceExplicite : IMonInterface
    {
        // Implémentation explicite d'une propriété
        string IMonInterface.UnePropriete { get; set; }
    }

Est-il vraiment besoin d'approfondir l'implémentation explicite d'une propriété d'une interface ? Cela se fait de la même manière que pour une méthode :
  • la visibilité n'est pas précisée (pas de public) ;
  • le nom de la propriété est précédée du nom de l'interface.


Les événements
L'implémentation explicite d'un événement est un moins intuitif. En effet, nous sommes obligés ici d'écrire explicitement les méthodes add et remove associées à l'événement en question :
Code C# : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
    public interface IMonInterface
    {
        event EventHandler UnEvenement;
    }
 
    public class InterfaceExplicite : IMonInterface
    {
        // Implémentation explicite d'un événement
        private EventHandler handler;
 
        event EventHandler IMonInterface.UnEvenement
        {
            add { handler += value; }
            remove { handler -= value; }
        }
    }

Il n'est pas possible d'implémenter automatiquement un événement explicite (chose possible avec un une implémentation implicite d'un événement). Autrement dit, la syntaxe suivante n'est pas supportée :
Code C# : Sélectionner tout - Visualiser dans une fenêtre à part
event EventHandler IMonInterface.UnEvenement;

alors que pour une implémentation implicite, celle-ci l'est :
Code C# : Sélectionner tout - Visualiser dans une fenêtre à part
public event EventHandler UnEvenement;

Pour le reste, c'est la même chose que pour les propriétés ou les méthodes : la visibilité n'est pas précisée, et le nom de l'événement est précédé par le nom de l'interface.

Conclusion
Voilà, maintenant, nous savons comment implémenter explicitement n'importe quel membre d'une interface, que ce soit une méthode, une propriété ou un événement.

L'implémentation explicite suit la même logique, quelque soit le type de membre. Seul l'implémentation des événements est un peu plus complexe dans la mesure où il est obligatoire de procéder à une implémentation complète.

Envoyer le billet « C# : Implémentation explicite des interfaces - Partie 4 » dans le blog Viadeo Envoyer le billet « C# : Implémentation explicite des interfaces - Partie 4 » dans le blog Twitter Envoyer le billet « C# : Implémentation explicite des interfaces - Partie 4 » dans le blog Google Envoyer le billet « C# : Implémentation explicite des interfaces - Partie 4 » dans le blog Facebook Envoyer le billet « C# : Implémentation explicite des interfaces - Partie 4 » dans le blog Digg Envoyer le billet « C# : Implémentation explicite des interfaces - Partie 4 » dans le blog Delicious Envoyer le billet « C# : Implémentation explicite des interfaces - Partie 4 » dans le blog MySpace Envoyer le billet « C# : Implémentation explicite des interfaces - Partie 4 » dans le blog Yahoo

Commentaires

  1. Avatar de lafarge
    • |
    • permalink
    Quelques ressemblance avec les Objets Com/DCom ! Non ??
  2. Avatar de François DORIN
    • |
    • permalink
    Sur quel(s) aspect(s) ?
  3. Avatar de lafarge
    • |
    • permalink
    Sur l'aspect contrat Interface - Implémentation. Ce dernier devant suivre scrupuleusement ce qui était défini dans l'interface. Enfin me semble t'il !
  4. Avatar de François DORIN
    • |
    • permalink
    Je crois que je ne comprenais pas votre question car je n'arrivais pas à faire le lien entre "interface explicite" et composants COM. Mais en fait, votre question, c'est le lien entre "interface" et composants COM.

    Le principe est effectivement similaire. Les interfaces sont quelques choses de courant et que l'on retrouve en principalement en Programmation Orienté Objet (mais pas que). Une classe doit impérativement et scrupuleusement respecter les interfaces dont elle dérive.

    Maintenant, la grosse différence que je vois, c'est qu'en POO, les interfaces sont généralement définies avant les classes. Les classes implémentent ensuite les interfaces pour respecter les contrats.

    Dans le cas des composants COM, l'implémentation du composant existe généralement avant, et on définie une interface afin de proposer une API publique d'accès à ce composant, pour pouvoir le réutiliser ensuite.

    Enfin, les deux sont très différents dans leur objectif. Les interfaces en POO ont pour rôle de créer de l'abstraction (en définissant un contrat), tandis que les composants COM ont pour rôle de permettre de réutiliser des composants, quelle que soit la technologie utilisée derrière.