Discussion :

[cobolfingaz]

Bonjour à tous,

Je ne suis pas certain de bien saisir le concept d'implémentation d'interface implicite. L'implémentation explicite me semble claire puisque les méthodes implémentées dans la classe sont préfixées par le nom de l'interface (je ne vois qu'une utilité à cela et c'est d'éviter les ambiguités lors de l'implementation multi-interface).

1. Y a-t-il d'autres utilités (que la désambiguation) à l'implémentation explicite d'interface ?

2. Quelqu'un pourrait m'expliquer l'implémentation implicite d'une interface ?

Quelques classes du Framework .NET exigent un cast vers l'interface décrivant la méthode que je veux appeler par la classe dérivée, et d'autres n'exigent pas de cast.

3. Quelqu'un peut me donner un exemple de définition de classe implémentant implicitement une interface, qui évite de devoir faire un cast vers l'interface ?

Merci beaucoup pour vos éclaircissements !

[tomlev]

1. Y a-t-il d'autres utilités (que la désambiguation) à l'implémentation explicite d'interface ?

Ca permet de déclarer dans ta classe une méthode qui a le même nom qu'une méthode d'une interface implémentée mais renvoie un type différent (plus spécialisé par exemple), tout en continuant à implémenter l'interface.

Par exemple, prends le cas de la classe DbConnection :

Elle implémente l'interface IDbConnection, et doit donc implémenter (entre autres) une méthode avec la signature suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

public IDbCommand CreateCommand();

Si on veut utiliser des méthodes spécifiques à DbCommand (qui n'existent pas dans IDbCommand), on est obligé de faire un cast, ce qui alourdit le code. Il faudrait donc que DbConnection.CreateCommand renvoie un DbCommand, mais celà ne correspond plus à la signature de l'interface. Pour rester conforme à l'interface, la méthode IDbCommand est implémentée explicitement. On a donc 2 méthodes CreateCommand dans classe DbConnection :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
// Implémentation locale de la méthode, non conforme à IDbConnection
public DbCommand CreateCommand();
// Implémentation explicite de l'interface pour rester conforme à IDbConnection
IDbCommand IDbConnection.CreateCommand();

Au final, si tu appelles la méthode CreateCommand via une variable de type DbConnection, ça renvoie un DbCommand. Si tu l'appelles via une variable IDbConnection, ça renvoie un IDbConnection. Petite illustration

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
DbConnection dbCnx = _factory.CreateConnection();
IDbConnection iDbCnx = dbCnx;
DbCommand dbCmd = dbCnx.CreateCommand(); // OK, renvoie un DbCommand
IDbCommand iDbCmd = iDbCnx.CreateCommand(); // OK renvoie unIDbCommand
IDbCommand iDbCmd2 = dbCnx.CreateCommand(); // OK, renvoie un DbCommand, qu'on peut affecter à un IDbCommand
DbCommand DbCmd2 = iDbCnx.CreateCommand(); // ne compile pas : IDbCommand n'est pas implicitement convertible en DbCommand

2. Quelqu'un pourrait m'expliquer l'implémentation implicite d'une interface ?

Ben c'est la manière "par défaut" d'implémenter une interface. Tu implémentes simplement des méthodes qui ont la même signature que celles de l'interface :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
interface I
{
    void MyMethod()
}
class C : I
{
    public void MyMethod()
    {
        Console.WriteLine(42);
    }
}

Quelques classes du Framework .NET exigent un cast vers l'interface décrivant la méthode que je veux appeler par la classe dérivée, et d'autres n'exigent pas de cast.

Si une classe C implémente une interface I, elle n'est pas obligée d'implémenter I implicitement, si elle le fait explicitement.
cf. l'explication ci-dessus sur l'implémentation explicite

3. Quelqu'un peut me donner un exemple de définition de classe implémentant implicitement une interface, qui évite de devoir faire un cast vers l'interface ?

cf. mon exemple pour la question 2

[oyigit]

Salut, une autre utilité, que je trouve génial permet de "masquer" certaines données ou méthode aux développeur. Je dit masquer entre guillemets, car quoi qu'on fasse, on ne peut rien masquer aux developpeur.

Je m'explique :
La structuration des classes, la définitation des accès (public, internal, private, protected...) permette de restreindre l'accès à certaines fonctions, propriété, classes... En faîte, il ne s'agit pas la d'une interdiction, on ne peut pas garantir qu'un développeur n'accèdera pas à un membre privé d'une classe, car avec l'introspection, c'est toujours possible. Le but en faîte, est de guider les développeurs, de leur indiquer qu'il ne doivent pas accéder à cette propriété. Lorsque tu à compris ce principe, tu comprend mieux le développement objet et tout son intérêt...

Pour en venir à notre cas précis, déclarer implicitement une interface va te permettre de masquer l'accès aux membres de l'interface. Ex, j'ai un objet Utilisateur qui implémente implicitement l'interface IDBUtilisateur décrite ci-dessous :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
public interface IDBUtilisateur
{
int id{get;set;}
DateTime dateDerniereConnexion{get;set;}
}

Les deux données de l'interface, sont en fait gérer par le moteur de mon application. C'est à dire que je ne veux pas qu'un développeur spécifie un identifiant explicitement, ou une date de dernière connexion explicitement (l'identifiant est un auto incrément, la date de derniere connexion est gérer dans une méthode de connexion par exemple). Dans la couche service de mon application, lorsque, par exemple je connecte un utilisateur, j'effectue un cast de l'objet utilisateur en IDBUtilisateur, je renseigne la date/heure actuelle, je met à jour ma base. Le développeur ne verra pas ce champ avec l'autocompletion. Alors bien entendu, il peut lui même faire un cast, mais l'objectif est toujours de guider le développeur, de lui faire prendre conscience qu'il est en train de faire un truc qu'il ne faut pas.
L'exemple n'est peut être pas très explicite, mais le principe est celui là.

Pour en venir à un cas de déclaration explicite :

Imaginons plusieurs classe nommés 'FormuleMathemique', 'FormulePhysique', 'FormuleChimique'... qui implémentent l'interface 'IFormule'

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
public interface IFormule
{
 FormuleResult GetResult();
}

Un développeur qui réalise une page devant afficher les résultat de différente formule de différents type pourra accéder explicitement aux résultats. En déclarant explicitement les méthodes, en faite tu indique à l'utilisateur qu'il est judicieux d'appeler ces méthodes

[tomlev]

déclarer implicitement une interface va te permettre de masquer l'accès aux membres de l'interface.

non justement, c'est l'implémentation explicite qui va permettre de "masquer" les membres...