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....

[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

[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

[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

[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.

[grinder59]

Je ne sais pas si je suis bien claire

Si j'ai bien compris, cela te force à implémenter les méthodes GetConnectionString et SetConnectionString dans toutes les classes représentant les types de connexions (sqlserver, mysql, firebird...)

Ainsi lorsque tu lances ton agent, quelque soit le type d'objet créé, tu es sûre que cet objet disposera des méthodes GetConnectionString et SetConnectionString pour pouvoir se connecter...

C'est ça ?

Toutefois, selon moi (je sens que j'ai tort, mais je ne comprends pas pourquoi), l'interface n'est pas ici obligatoire pour que ton programme fonctionne. Même sans interface, tu peux implémenter les méthodes Get... et Set... dans toutes tes classes pour que ton programme fonctionne ! Sans interface, il faudra y penser à chaque nouveau plugin, alors qu'avec l'interface, le compilateur te rappellera d'éventuels oublis. Est-ce ça l'utilité de l'interface ?

[youtpout978]

Comment appelerait tu ces méthodes si tout tes objets sont différents et n'implemente pas une interface, fait ce qu'elle essaye de faire sans utiliser d'interface ni d'heriter d'un objet commun qui a ces 2 méthodes, tu vas vite comprendre le pb et la difficulté de mise en oeuvre, surtout si tu en ajoutes d'autres par la suite.

[grinder59]

Code :

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

1
2
3
4
5
6
//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);
}

Dans ce cas, l'interface permet de manipuler des objets dont on ne connaît pas le type mais dont on sait qu'ils disposent forcément de la méthode Nourrir.

On aurait utilisé l'héritage si tous les êtres se nourrissaient de la même façon, mais comme ce n'est pas le cas, on utilise une interface pour avoir des implémentation au cas par cas de Nourrir(). J'ai bon en disant ça ?

[youtpout978]

Oui tu as bon

[grinder59]

Comment appelerait tu ces méthodes si tout tes objets sont différents et nimplemente pas une interface fait ce qu'elle essaye de faire sans utiliser dinterface et dheriter dun objet commun qui a ces 2 méthodes, tu vas vite comprendre le pb et la difficulté de mise en oeuvre surtout si tu en ajoutes d'autres par la suite.

Je pense commencer à comprendre... (je sais, je suis lent...)

L'interface permet d'avoir un type commun à tous les objets qui l'implémente, ainsi en développement, on n'a pas à savoir quel type on utilisera à l'exécution du programme, mais on sait que, quelque soit le type choisi, on aura les 2 méthodes implémentées associées à l'objet créé.

En cas d'ajout d'un type de connexion, dois-je également toucher au programme principal ou seul le codage du plugin suffit ?

Code :

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

1
2
3
4
 
	public void NourrirMonEtre(IVivant monEtre,object nourriture){
		monEtre.Nourrir(nourriture);
	}

En supposant que, dans mon programme principal, j'appelle la méthode NourrirMonEtre. Dans l'appel, je dois lui passer un objet de type Humain, Pieuvre ou Moustique, right ?

Et si je suis Dieu (pas en C# en tous cas) et que je crée un nouveau type d'être vivant :

Code :

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

1
2
3
4
 
public class Limace:IVivant{
    public void Nourrir(object Nourriture)
}

Je devrais également modifier le code de mon programme principal pour qu'il prenne en charge le cas d'un objet de type Limace, c'est ça ?

En tentant de mettre en oeuvre l'exemple de alucia :

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
35
36
37
38
39
40
41
42
43
 
public interface IOdbcLink{
	public string GetConnectionString(){}
	public void SetConnectionString(string c){}
}
 
public Mysql:IOdbcLink{
	string chaine;
	public string GetConnectionString(){
		// traitement spécifique à Mysql
	}
	public void SetConnectionString(string c){
		// traitement spécifique à Mysql
	}
}
 
public Access:IOdbcLink{
	string chaine;
	public string GetConnectionString(){
		// traitement spécifique à Access
	}
	public void SetConnectionString(string c){
		// traitement spécifique à Access
	}
}
 
public ClassePrincipal{
 
 
	public static void Main(args[]){
 
		IOdbcLink connexion;
		if (choix user == connexion mysql){
			connexion = new Mysql();
		}
		if (choix user == connexion access){
			connexion = new Acess();
		}
		connexion.SetConnectionString(parametres de connexion);
		connexion.GetConnectionString(parametres de connexion);
	}
 
}

Si j'ajoute le support des connexion SQL Server, je ne dois que :
1. créer le plugin :

Code :

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

public Sqlserver:IOdbcLink{...}

2. ajouter l'instanciation de l'objet dans le programme principal :

Code :

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

1
2
3
4
 
	if (choix user == connexion sql server){
		connexion = new Sqlserver();
	}

et tout mon programme fonctionne sans autre modification...

Est-ce que cet exemple est juste ? Si oui, est-ce qu'il illustre correctement l'intérêt principal des interfaces ?

[alucia]

Oui c'est ça l'idée ^^ pouvoir rajouter des fonctionnalités sans avoir a tout recoder.
Dans mon cas l'interface est réellement indispensable car je ne connais pas mes classes à la compilation; elles ne sont présentes qu'au moment de l'exécution.

par ex je ne peux pas faire :

Code :

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

1
2
 OdbcPluginSQLServer obj = new OdbcPluginSQLServer() 
string connString = obj.GetConnectionString()

Car cette classe n'est pas définie au moment où je code mon application, le compilateur me répondrait qu'il ne connait pas OdbcPluginSQLServer.

Concrètement j'ai une liste List<IOdbcLink> qui se remplira avec chaque classe trouvée implémentant cette interface (grosso modo en cherchant dans les dll de mes plugins, que je range toutes dans le même dossier; mais c'est un peu compliqué ).
L'interface possède aussi une méthode GetDatabaseType() qui me renvoit un string contenant le type de la base ("SQL Server", "MS Access" ...).

A l'exécution, je suis obligée de procéder comme ceci :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
// Recherche dans la List<IOdbcLink> un objet dont la méthode GetDatabaseType correspond à dbType (chaine de caracteres contenant le type de la base choisie)
// ==> recherche du plugin de connexion pour une base de données SQL Server
IOdbcLink plugin = m_TemplistOfOdbcPlugin.Find(
                                    delegate(IOdbcPlugin pluginSearch) { return pluginSearch.GetDatabaseType() == dbType ;}); 
// OdbcLink est une classe réelle qui ne contient aucune méthode, seulement les attributs représentant un lien ODBC 
// instanciation d'un nouvel objet OdbcLink
                                OdbcLink _odbcLink = new OdbcLink();
// Je passe par mon interface pour initialiser la connection string : 
// plugin contient un objet issu de la classe qui correspondait à mon critère, mais j'ignore son nom : je dois passer par mon interface
                                plugin.SetConnectionString(serverName, userName, databaseName);
// J'initialise mon réel objet OdbcLink à l'aide de mon plugin
                                _odbcLink.ConnectionString = plugin.GetConnectionString();
// J'ai maintenant un objet _odbcLink initialisé correctement, sans savoir quelle base a été choisie

Les interfaces sont très utilisées pour la programamtion modulaire, avec des plugins

[antoine.debyser]

Je devrais également modifier le code de mon programme principal pour qu'il prenne en charge le cas d'un objet de type Limace, c'est ça ?

Bonjour,
Non justement tu n'as pas a modifier ton programme.

En utilisant d'autres terme, avec un interface tu définis une responsabilité. Alors qu'avec un héritage tu définis une ressemblance.
Dans l'exemple de IVivant, les classes qui vont implémenter IVivant sont alors responsable du fait de se nourir. Ton programme n'a pas besoin de connaitre les classes, il a juste a verifier la responsabilité et s'appuyer deçus.

C'est exactement ce que décrit alucia, le programme charge des "dll" à la voler, cherche des classe ayant la responsabilité IOdbcLink, et du coup il (le programme) peut travailler avec, il n'a pas besoin d'en savoir plus.

Pour revenir sur l’héritage multiple, c'est erreur des débuts de la programmation objet.
Une classe ne peut ressembler au deux choses en même temps, alors que ces choses sont complétement différentes.
Ce qui te gène dans les interfaces et que tu apprécie dans l’héritage multiple, c'est la réutilisation de code.
C'est un faux probleme prenons le cas IVivant.
L'humain et la pieuvre mange tous les deux des poissons.

Donc pour partager du code je vais ecrir cette classe

Code :

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

class MangeurPoisson { public void Manger(Poisson nourriture) { /*... */ } }

Et Humain sera implemanter comme ceci

Code :

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

1
2
3
4
5
6
7
8
9
10
11
class Humain : IVivant
{
public Nourrir(object nourriture)
{
  if (nourriture is Poisson)
  {
    MangeurPoisson mangeur = new MangeurPoisson();
    mangeur.Manger((Poisson)nourriture);
  }
}
}

Ainsi le comportement lié aux aliments de type Poisson est partagé, et ma responsabilité "Vivant" est bien définit.