Discussion :

[maa]

Bonjour,

Je me demande pourquoi il n'est pas possible, en .net, de dire qu'une classe implémente automatiquement une interface si sa signature correspond à celle de l'interface et sans qu'on est besoin de préciser explicitement qu'elle l'implémente.

Par exemple :

Code :

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

1
2
3
4
5
6
7
8
9
10
 
interface IInterface
{
string PropertyA {get; set;}
}
 
class ClasseA
{
public string PropertyA {get; set;}
}

Ça serait bien si on pouvait directement utiliser une instance ClasseA en tant que IInterface. C'est pas que je sois fainéant au point de ne pas vouloir écrire ":IInterface", mais bien souvent on aimerait qu'une classe implémente une interface (et elle l'implémente effectivement au niveau de la signature), mais on ne peut pas accéder aux sources. Évidement le dp adaptateur est possible mais il n'est pas léger à implémenter ni très efficace puisqu'on crée un wrapper pour chaque classe à implémenter.

Je ne vois que peux d'avantage à être obligé d'écrire : ":IInterface"
- Il est vrai que cela force à être plus lisible. On peut voir très rapidement quelles interfaces implémentent une classe. Si on n'avait la possibilité de ne pas l'écrire, on aurait certainement un code moins lisible.
- Cela permet d'être sûr qu'il n'y a pas d'ambiguïté. 2 classes pourraient avoir une même signature mais les membres pourrait avoir des significations totalement différentes. En implémentant une interface on la relie à un ensemble de classe ayant un sens commun.

Avec l'arrivée de c#4 et des types dynamiques, je pense que les choses sont un peu différentes car on peut maintenant invoquer un membre d'une classe sans qu'il n'existe, la vérification étant faite à l'exécution. Je pense que cela est de toute façon plus dangereux que de risquer d'invoquer un membre existant qui n'a pas le sens attendu.

Que pensez vous de tout cela ? Pensez-vous que l'on pourra implicitement implémenter une interface avec l'arrivée du framework 4 ?

Merci d'avance pour vos remarques.

[tomlev]

- Cela permet d'être sûr qu'il n'y a pas d'ambiguïté. 2 classes pourraient avoir une même signature mais les membres pourrait avoir des significations totalement différentes. En implémentant une interface on la relie à un ensemble de classe ayant un sens commun.

A mon avis, à lui seul ce point justifie qu'on déclare explicitement l'interface implémentée...

[maa]

A mon avis, à lui seul ce point justifie qu'on déclare explicitement l'interface implémentée...

oui mais avec c#4, il y a ce point :

Avec l'arrivée de c#4 et des types dynamiques, je pense que les choses sont un peu différentes car on peut maintenant invoquer un membre d'une classe sans qu'il n'existe, la vérification étant faite à l'exécution. Je pense que cela est de toute façon plus dangereux que de risquer d'invoquer un membre existant qui n'a pas le sens attendu.

[Gold Bug]

Je me demande pourquoi il n'est pas possible, en .net, de dire qu'une classe implémente automatiquement une interface si sa signature correspond à celle de l'interface et sans qu'on est besoin de préciser explicitement qu'elle l'implémente.

Probablement parce que personne n'y avait jamais pensé avant toi

Blague à part, je pense qu'un compilo comme celui de C# serait techniquement capable de faire ce que tu dis.
Mais ouvrir cette porte a de nombreux inconvénients :
- Quand tu implémentes une interface qui est partagée entre plusieurs projets/collègues, si l'interface change, tu dois adapter ton code sinon il ne compiles plus. Dans le cas que tu présentes, la classe va continuer à compiler, mais elle plantera à l'exécution. C'est beaucoup plus difficile à débugger et à maintenir.
- Les diagrammes de classes auront-il encore un sens, sachant qu'on se retrouvera avec des classes qui n'implémentent pas les interfaces en C# alors qu'elles les implémentent sur le diagramme UML ?
- Le reverse-engineering devient mission impossible (bon d'accord, c'est souvent déjà le cas )

[maa]

Je pense en effet que le comportement par défaut devrait rester celui qu'il est.
Mais on pourrait ajouter un mot clé "implicit" devant la déclaration d'une interface.
Une telle interface ne pourrait alors être utilisée par des méthodes que si celle-ci déclare ses paramètres du type de l'interface comme "implicit"

Donc quelque chose de ce style :

implicit interface IInterface
{
string PropertyA {get; set;}
}

class ClasseA
{
public string PropertyA {get; set;}
}

public void AMethod(implicit IInterface p)
{
}

//et on pourrait appeler comme ceci :
AMethod(new ClassA());

Cela permettrait d'éviter d'écrire :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
public void AMethod(object p)
{
    if(p is type1)
        var p1 = p as type1
        ...
    else if(p is type2)
        var p2 = p as type2
        ...
    else if(p is type3)
        var p3 = p as type3
        ...
    endif
}

Qui risque beaucoup plus de planter à l'exécution puisqu'on ne fait même pas de vérification sur la signature de la classe...

[Guulh]

C'est possible en C++ avec les templates. En gros, si tu écris en C++ (me souviens plus de la syntaxe exacte)

Code :

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

public T Machin<T>(T item) { return item + 1; }

le compilo ne dira rien si tu n'utilises jamais la méthode. Par contre, dès que tu l'utilises sur un certain type (disons int), le compilo va créer une version de la méthode propre au type int, et donc

Code :

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

public int Machin(int item) {return item +1; }

, qui compile correctement parce que l'on peyut ajouter 1 à un int. Mais c'est parce que les template sont très différents des generics, malgré une syntaxe et un usage voisin. Ici, si tu appelles la fonction Machin sur un type T à toi qui n'a pas d'operator+ prenant un int, tu te prendras une jolie erreur de compil bien incompréhensible.

Ce que tu demandes serait possible en C++ :

Code :

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

1
2
3
4
5
public void AMethod<T>(T p)
{
  ...
  ... p.PropertyA;
}

Parce que en fait t'auras autant de méthodes AMethod que de type différents avec lequel tu l'as appelée.

[maa]

Je ne comprends pas trop pourquoi on sait que p à une propriété A.

[Guulh]

C'est parce que les template C++ ne sont que des macros, en fait. En soi, elles n'ont pas à être correctes syntaxiquement. S'il y a dans ton code

Code :

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

1
2
3
4
5
void f()
{
   Machin(4);
   Machin("bob");
}

Le compilo va créer deux fonctions machin, l'une pour int, l'autre pour string ; et c'est après les avoir créées qu'il va essayer de les compiler et vérifier leur syntaxe.
Alors qu'en C#, le compilo peut indépendamment des éventuels appels vérifier la syntaxe d'une méthode générique

'fin je parlais de tout ça pour dire ton idée est loin d'être bizarre, puisqu'elle est réalisable (au moins) en C++