Discussion :

[grinder59]

Bonjour,

en cours d'auto-formation en C#, j'en suis à l'étude des classes dérivées et des interfaces. Si techniquement, c'est pas bien compliqué, je me pose néanmoins cette question existentielle : Quel est l'intérêt réel d'une interface ?

J'ai bien compris qu'il s'agissait d'un contrat nécessitant, pour la classe qui en "dérive" (sorry si le terme n'est pas exact), d'implémenter toutes les méthodes de cette interface, néanmoins, en terme d'optimisation, l'héritage est bien plus puissant ! Dans mon cours, les interfaces sont présentées comme une alternative à l'héritage multiple, mais dans la mesure où je suis obligé d'implémenter toutes les méthodes de l'interface dans la classe, quel est le gain ?

Suis-je passé à côté de quelque chose ?
L'interface est-elle juste un mécanisme permettant de garantir la présence de méthodes dans une classe qui en dérive (ce qui, j'en conviens, est déjà un concept intéressant) ?
L'interface est-elle vraiment une alternative à l'héritage multiple ?

Merci de vos lumières !

[BenoitM]

L'héritage c'est un lien fort. Mère->Enfant
L'interface est un ensemble de fonctionnalités (contrat).

On ne peut hérité que d'une seule classe mère, tandis qu'on peut implémenter plusieurs interfaces.


Par exemple tu as l'interface IComparable pour signaler que tu peux comparer 2 objets de la même classe.
Par exemple une classe Rectangle pour savoir lequel des deux est le plus grand
Il est logique de vouloir comparer 2 string (pour les tier) et de comparer 2 rectangles (pour savoir lequel est le plus grand) mais un string et un rectangle n'ont aucun lien entre eux

L'interface est-elle juste un mécanisme permettant de garantir la présence de méthodes dans une classe qui en dérive

On parle d'implémentation pas de dérive (héritage)

L'interface est-elle vraiment une alternative à l'héritage multiple ?

Euh personnellement je dirai que c'est une solution à l'absence d'héritage multiple mais ce n'est pas son rôle principale

[Er3van]

Je réponds dans le désordre, mais je pense que ça sera plus simple à comprendre.

L'interface est-elle vraiment une alternative à l'héritage multiple ?

Non.
Bien que techniquement, les interfaces peuvent te permettent de contourner le blocage volontaire en .Net qui t'empêche d'hériter de deux classes, ce n'est pas le but.
Et avec un peu de recul, quand tu veux hériter de deux classes, c'est généralement qu'il y a un problème de conception quelque part.

L'interface est-elle juste un mécanisme permettant de garantir la présence de méthodes dans une classe qui en dérive (ce qui, j'en conviens, est déjà un concept intéressant) ?

Oui, à ceci près que c'est déjà pas mal !

En fait, pense à la situation suivante. Je prends un exemple débilissime, mais pour comprendre cela devrait suffire je l'espère.

Je définis une classe banane, qui hérite de ma classe fruit
Je définis également une classe fraise, une classe noix de coco et une classe Belladone (pour ceux à qui ça ne parle pas, c'est une baïe toxique).

Bien que tous ces éléments soient des fruits, j'ai besoin de plus d'informations.
Je veux notamment savoir si c'est fruits sont comestibles auquel cas je veux savoir leur taux de sucre, et si je peux les mettre dans mon mixeur, auquel cas je veux savoir le rapport de jus/masse du fruit.
Pour cela, j'implémente les interfaces suivantes :

Code c# :

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

1
2
3
4
5
6
7
public interface IEatable {
    public double GetSugarRatio();
}
 
public interface IMixable {
    public double GetJuceWeightRatio();
}

Et certaines de mes classes vont implémenter les interfaces qui conviennent, et donc je vais les contraindre à implémenter les méthodes pour avoir les informations que je souhaite.

On aura donc :

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
17
18
19
 
public class Banana : Fruit, IEatable , IMixable {
    ....
    public double GetSugarRatio() { ... }
    public double GetJuceWeightRatio() { .... }
}
public class Strawberry: Fruit, IEatable , IMixable {
    ....
    public double GetSugarRatio() { ... }
    public double GetJuceWeightRatio() { .... }
}
public class Belladonna: Fruit, IMixable { /* Oui... c'est débile, mais on peut mixer un élément toxique ! xD */
    ....
    public double GetJuceWeightRatio() { .... }
}
public class Coconut : Fruit, IEatable { /* Très dur à mixer, mais ça se mange ! */
    ....
    public double GetJuceWeightRatio() { .... }
}

[BenoitM]

...

C'est quoi le jus de fruit/smoothie du jour

[grinder59]

Merci de vos réponses.
Si je reprends l'exemple des fruits, le fait que la classe Banana et Strawberry implémentent la classe IEatable oblige l'implémentations dans ces classes de la méthode de IEatable GetSugarRatio().

Toutefois si GetSugarRatio() a une implémentation identique dans la classe Banana et Strawberry, je ne comprends pas bien la valeur ajoutée de l'interface puisque j'aurai 2 fois le même code...

C'est quoi le jus de fruit/smoothie du jour

Code :

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

1
2
3
public Smoothie getDailyJuice(){
return Smoothie->getJuice(Belladone);
}

[Er3van]

Je ne suis pas allé assez loin dans l'exemple, diantre !

Disons que pour calculer le taux de sucre, le calcul entre entre une banane et une fraise est peut-être différent, et donc que l'implémentation pourra être différente. En tout cas, tu laisse la liberté à ta classe de l'implémentation.

Si ça doit être commun, tu peux l'avoir au niveau de la classe Fruit. Mais l'interface te permet dans ce cas de faire la distinction malgré tout.

Code :

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

If (myFruit is IEatable) { .... }

[grinder59]

Ok... Dans vos expériences personnelles, vous est-il déjà arriver d'utiliser les interfaces lors de développements solo ? (sans équipe et sans autre développeur que vous même)

[Er3van]

Oui !
Voire peut-être même plus que dans mes développements pro... je me sers beaucoup des interfaces pour définir les comportements transverses.

Par exemple, un Spaceship qui est IMoveable, IHabitable, IRepearable, IDestructible, IManufacturable....

[grinder59]

Par exemple, un Spaceship qui est IMoveable, IHabitable, IRepearable, IDestructible, IManufacturable....

ça te permet d'avoir un "aide mémoire" sur les comportements que tes objets doivent implémenter ?

Et le steakaché aussi? :p

[youtpout978]

pour moi un des réels intérêts de l'interface est de pouvoir appeler ton objet qui l'implémente en tant que tel (avant aussi je ne comprenait pas son utilité).

Tu peux avoir des objet complètement différent:

Code :

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
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
 
public Interface IVivant
{
public void Nourrir(object Nourriture);
}
 
public class Humain:IVivant { }
 
public class Pieuvre:IVivant { }
 
public class Moustique:IVivant { }
 
//Tu as dans une autre classe une méthode qui permet de nourrir un être vivant sans savoir de quel type il est mais tu sais qu'il implément l'interface Ivivant, tu peux faire ça:
 
public void NourrirMonEtre(IVivant monEtre,object nourriture)
{
monEtre.Nourrir(nourriture);
}
 
//ou tu peux avoir toute sorte d'objet et le nourrir que s'il implémente l'interface:
 
public bool NourrirMonEtre(object monObjet,object nourriture)
{
Ivivant monEtre=monObjet as Ivivant;
if(monEtre!=null)
{
monEtre.Nourrir(nourriture);
return true;
}
else
{
return false;
}
}

je ne sais pas si c'est un bon exemple, après dans le framework tu as des interface très utile que le framework utilise pour communiquer avec tes objets comme INotifyPropertyChanged, IDisposable...

[BenoitM]

ça te permet d'avoir un "aide mémoire" sur les comportements que tes objets doivent implémenter ?

Ca permet une plus grande abstraction et indépendance entre des fonctionnalités et des objets.

[alucia]

J'en utilise actuellement pour mon projet dans le cadre de mes études

je dois développer un agent permettant de récupérer tous les liens ODBC existant sur un serveur et de créer les connectionstring associées en fonction de ces liens.

Or, les connection string sont construites de manière différente selon le type de base (SQL Server, Oracle, MySQL, etc.).

Mon agent permet à l'utilisateur de choisir la base à laquelle il veut se connecter, par conséquent lorsque je code la connexion à la base, je ne peux pas savoir à l'avance laquelle il aura choisie, ni même combien il y en a et de quel type elles sont.

C'est pourquoi j'utilise des plugins : je développe une classe par type de base de données pour créer les connectionstring.
Toutes ces classes implémentent donc une interface IOdbcLink, qui exige une methode GetConnectionString() et SetConnectionString().

De cette manière, lorsque je lance mon agent, je vais charger dynamiquement les dll contenant les classes que j'ai déjà définies, et sans forcément savoir laquelle sera utilisée après je vais pouvoir récupérer la connectionstring de la base que l'utilisateur aura choisi.

Comme mes classes ne sont pas connues avant l'exécution, la seule que je sais quand je code, c'est que la classe qui sera chargée implémentera forcément IOdbcLink.
Sans cette interface, je ne pourrais pas appeler la méthode GetConnectionString().

Je ne sais pas si je suis bien claire

[BenoitM]

et le jour où quelqu'un veut mettre de la légumes dans le robot sans interface IMixable , il va dérivé ses légumes de fruit?
Et le steakaché aussi? :p