[C#] A quoi servent les interfaces???

Bonjour,

J'étudie le langage C# pour programmer sous la plateforme .NET.
J'ai beau essayé de comprendre sur les boukins, sur le net, mais je n'y arrive pas.
Alors je pose ma question : à quoi peut servir les interfaces en C# ??? Je n'en vois pas du tout l'utilité, car une interface ne fait que désigner le nom des fonctions qui seront utilisées par des classes qui les implementeront, ni plus ni moins.
Alors pkoi ne pas creer tout simplement ces fonctions dans les classes, et les appeler à l'aide des objets??

Voilà, j'espere que quelqu'un reussira à (enfin) me faire comprendre avec un exemple simple l'utilité des interfaces, et surtout quand est-ce que je devrai les utiliser (cas concret) ?

Merci à tous,

SoF

Salut

Citation:

---

Je n'en vois pas du tout l'utilité, car une interface ne fait que désigner le nom des fonctions qui seront utilisées par des classes qui les implementeront, ni plus ni moins.

---

deja la premiere chose dont il faut te rendre compte au niveau de la POO: une classe peut contenir des donees sans forcement contenir d'actions.

Je vais t'expliquer ca d'un point de vue tres pratiques: dans quels cas on lpeut l'utiliser (en code vb simplifie, car j'ai sommeil)

L'interface a deux roles:

:arrow: Role de substitution de classes differentes.

Prenons l'exemple des Classes qui permettent de se connecter aux bases de donees (elles se trouvent dans system.data) Si tu veux developper ton soft pour qu'il utilise une base de donnee, disons access, tu vas utiliser system.data.oledb
Si un jour pouvoir utiliser un autre type de base, disons mysql. Comment vas-tu faire sans avoir a changer le code de partout ? Comment peux tu faire sans dupliquer du code qui fera la meme chose mais pour deux bases differentes ?
La reponse est simple. Toutes les sous classes des differentes classes te permettant de travailler avec les bases de donnees implementent les memes interfaces.
Par exemple OleDbConnection pour se connecter a Access et SqlConnection pour se connecter a SQL server, implementent toutes les deux IdbConnection

ton code access qui serait:

Code:

---

1 2 3 4 5 6 7

Class travail dim cn as OledbConnection cn.connectionstring = ... cn.open ... End class

---

Devient pour que ton programme soit multi-base de donnees:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

Class travail dim cn as IdbConnection cn = RecupererConnection("Access") cn.connectionstring = ... cn.open ... End class   Class DAL Function RecupererConnection(base as string) as IdbConnection If base = "access" then Return cn as new OledbConnection else Return cn as new SqlConnection End if end class

---

En gros que tu fasses de l'access ou du SQL server: ton code le plus important restera COMMUN quelque soit la base de donnee que tu vas choisir.


:arrow: Role de succession de classes

Bon je fatigue je vais faire vite :P
Imagine que ton soft doit composer des produits differents pour en creer un nouveau. Imagine aussi que tu vas devoir faire des actions sur les sous produits qui composent le produit: par exemple calculer le cout total, sachant que chaque sous produit etant completement different, ils aient neamoins en commun une propriete cout

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

Class ProduitCompose1 ContenanceEnLitres as int32 HauteurDuBidon as Decimal CoutUnitaire as Decimal ... end Class   Class ProduitCompose2 PoidEnKg as decimal DateDePeremption as Date CoutUnitaire as Decimal end class   Class ProduitFini Function CalculerCoutTotal ... ? ... End Function End class

---

Pour calculer le cout total avec 2 composes, ok c'est simple, mais imagine que t'en as 10 tous differnts! Tu dois creer une variable pour chaque composant possible! Comment tu fais si un jour tu as un nouveau composant ? tu recodes ? :lol:

Bin non: tu cree une interface avec CoutUnitaire, tu peux donc stocker uniforment tes composants dans une collection et parcourir les objets en additionnant la propriete qu'ils ont en commun: Cout total
Tout devient plus simple

Pour encore aller plus loin: imagine carrement un "arbre" de composants!

Reponse:

Code:

---

1 2 3 4 5 6 7 8

Interface ISousProduit Property CoutUnitaire 'un array de ISousProduit ! SousProduits() as ISousProduit 'la fonction qui va faire la somme de couts unitaires des sous produits si elle en possede OU de son cout unutaire si elle en a un Function calculerCout as Decimal end Interface

---

Bon j'ai ete un peu rapide et pas tres detaille, ca fait un moment que j'ecris justement un tuto la dessus, j'espere au moins que tu auras compris que ca sert et que ca sert beaucoup !

8)

good night

C’est simple les interface cache l’implémentation de tes classe CAD c’est la façade de tes objet c’est la clés du couplage faible entre les objet et la porte a la réutilisation et
Sache que c’est le concept far des architectures modernes SOA…
Essais de trouvé des doc de la POO qui explique bien ses mécanisme par ce que
C# et autre te montre comment ces langage prenne en charge ses technique mais pas le concept lui-même si tu te forme bien a la POO en quelque sorte tu te forme a n’importe quelle langage qui prend en charge ses technique c# java……
Alors un bon conseil casse toi la tête par ce que c’est les fondement de la prog

Bonjour
Si j'ai bien compris ce que j'ai lu dans un excellent livre pour débuter avec C# (excellent veux dire "à ma portée" :wink: ), une interface permet d'obtenir un effet similaire à l'héritage multiple qui est impossible en C#. Elle serait assez similaire à une classe abstraite.
Tous ses membres sont présumés public Elle ne possède que des méthodes et des propriétés. Une classe peut hériter de plusieurs interfaces alors qu'elle ne peut hériter que d'une seule classe. De plus, les structures peuvent implémenter des interfaces, alors qu'elle ne peuvent pas implamétenter une autre strucutture ou une classe.
Pour terminer, le titre du bouquin: C# en 21 jours, de Bradley L.Jones, chez Campus Press, collectiion "Le programmeur". Malgré son titre accrocheur et quelquepeu optimiste, le livre est à la portée d'un débutant.

Salut à tous,

Je tiens à vous remercier pour les infos que vous m'avez donné sur les interfaces. En effet je vois que c'est un concept IMPORTANT à la POO.
Je ne voyais pas l'interet de les utiliser, car ar il est obligatoire à la classe qui l'implemente de redéfenir la fonction. Mais je crois que mon problem est lié à l'utilisation des interfaces...

Piotrek-----> apres avoir bien relu ton exemple, j'avoue que ça me semble à present beaucoup moins flou, un grand MERCI. Tu dis avoir fais un tuto la dessus, si tu pouvais me balancer l'url ce serait cool.

A bientot...

heu

"en train de faire depuis 3 mois" serait plus approprie :oops:
Le probleme pour moi est: comment tout presenter d'une maniere claire simple et evolutive... j'y arriverais :)

Tu peux trouver d'autres tutos ici en attendant:
http://dotnet.developpez.com/

Mais Dich va en sortir un sous peu pour l'acces aux bases de donnees avec l'utilisation des interfaces, c'est mon petit doigt qui me l'a dit
:P

Si tu le presentes comme ton explication plus haut... il risque d'etre "claire, simple et évolutive" : )

Pour le moment j'irai faire un tour sur le forum, en attendant vos tutos...

Merci encore,

@ +++

Je confirme la sortie dans une bonne semaine (normalement)

Une interface, c'est un contrat dans lequel y est décrit des méthodes.
Toutes les classes qui implémentent cet interface doivent respecter ce contrat, c'est-à-dire qu'elles doivent tous posséder tous les méthodes décrites dans l'interface.

A quoi ca sert?
A faire des programmes complexes, robustes et évolutives.

Comment?
L'interface définit un contrat, si une classe ne respecte pas ce contrat, le compilateur te prévient.
La plupart des "design pattern" sont à base de classes abstraites et d'interfaces. Donc leur utilisation revient à utiliser des interfaces (dans la majoritées des cas).
Si dans un projet, une équipe de développeur s'occupent de la partie IHM et une autre de la partie modèle métier. Les architectes peuvent définir les interfaces que les 2 équipes doivent respecter.

Inconvénients:
Demande un plus haut niveau d'abstraction.
Parfois trop de réflection avant de coder.
La modification d'une interface implique la modification de toutes les classes qui l'implémente.
Parfois, c'est une facon de faire compliquer quand on peut faire simple.

Conclusion:
Oui, les interfaces, mais ne pas trop en abuser.