Version imprimable
;) salut tout le monde
c# c# c# c# c# c# c# c# c# c# c# c#
S.V.P si qq'un peut m'expliquer l'importance des interfaces puisqu'on va implémenter les mêthodes qu'elles contiennent dans dans toute classe qui a recours à ces mêthodes, une chose qu'on peut bien faire sans ces interfaces
je n'arrive vraiment pas à toucher l'utilité
;) encore une question:
pourquoi le terme "interface"
merci beaucoup
C'est très simple, prenons un exemple concret avec les bases de données et les interfaces IDataReader.
Tu as une base de données SqlServer, et tu veux une méthode M qui renvoie un DataReader. Dans ton cas tu renvoies un SqlDataReader. Juste là ça marche. Admettons maintenant que tu veuilles passer sous une base Oracle. Tu es en train de te dire "bah c'est pas grave, je remplace mon SqlDataReader par un OracleDataReader dans les méthodes qui en ont besoin".
C'est une solution mais tu perds un temps précieux.
En regardant la définition de SqlDataReader et OracleDataReader, tu vois que les deux implémentent IDataReader.
Dans ton cas, M, au lieu de renvoyer un SqlDataReader devrait renvoyer un IDataReader. Dans le code qui appelle M tu n'aurais rien eu à changer vu que dans les deux cas, tu obtiens un IDataReader. Tu n'aurais eu qu'à modifier le corps de M.
De manière générale, les interfaces permettent d'ajouter un niveau d'abstraction pour pouvoir faire des changements dans une couche de l'application sans avoir à modifier les couches supérieures.
Typiquement un Web Service devrait toujours prendre en paramètre et retourner des interfaces, histoire de découpler au maximum le Web Service et les applications qui l'utilisent.
Les interfaces sont un concept POO, c'est beaucoup plus généraliste que C# ;)
Lis un bouquin (online ou pas) sur les concepts POO tu comprendra très vite l'énorme utilité.
En clair, imagines que tu t'amuses à réaliser un programme qui manipule des véhicules.
Tu as plein de véhicules différents... Avion, Voiture, Charette.... Tricycle....
Et tu pour te simplifier la vie, au lieu d'avoir 200000 variables différentes, tu utilises une liste (logique non ?)
Donc on va dire List<T> ça parait un très bon choix.
Problème... List<T> demande un type particulier.... Bon, il faudrait pouvoir dire qu'on veut mettre des véhicules dans cette liste. Alors... List<Avion> ? List<Voiture> ?
Bon, finalement, pas pratique cette List<T>, on va utiliser un ArrayList (qui correspond à List<object> en fait), comme ça on peut mettre ce qu'on veut dedans...
Alors...
ArrayList maListe = new ArrayList();
[blablabla...]
maListe.add(new Avion());
maListe.add(new Voiture());
maListe.add(new....);
etc...
Cool, on a notre liste bien remplie.
Bon, maintenant, le problème, c'est qu'on aimerait bien démarrer un de ces appareils (mettre le contact quoi).
Alors, on fait comment, dans la mesure où on a que les types Avion, Voiture, Bicyclette....
if(maListe[i] is Avion){
(maListe[i] as Avion).demarrer();
}else if(maListe[i] is Voiture){
.... blablabla
C'est galère non ?
Alors, au lieu de se faire chier avec ces spaghettis, on utilise une interface qui implémente demarrer();
C'est beaucoup plus simple que l'immonde armée des if imbriqués non ?Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
Ouais c'est bien beau tout ça, mais il y a quand même une faille dans ton raisonnement :
Comment tu démarres un vélo ?Citation:
on a que les types Avion, Voiture, Bicyclette
Ouais je sors... :mouarf:
PS : Je me demandais : "l'immonde armée des if imbriqués", ça serait pas un film de Romero ?
Tu connais pas les solex ? :p
Salut tout le monde
je vous demande pardon mais je crois que j'ai mal pauser ma question, je comprends tout ce que vous avez dit mais, mon problème :calim2: et je ne sais pas si je doit pas poser cette question!:calim2: :
quel est l'interêt de créer une chose dit interface qui ne contient que des déclarrations de membres, si je vais ensuite créer des classes dans lesquelles on va dééclarrer et implémenterai ces membres .
:arf:
Autrement dit qu'y a-t-il de différent si je déclarre et implémente ces membre tout simplement et directement dans la classe sans avoir à dériver d'une interface .
SaumonAgile a parlé de gasspille de temps mais il a donné un exemple par Idatareader mais moi je ne sais pas encore rien sur les base de données. je souhaite que qq'un puisse me donner un exemple simple.
Merci vivement
Bonsoir
noubigh les interfaces sont des "contrats" passés avec les classes qui les implémentent, en fait un exemple d'utilisation qui peu aider à comprendre leur utilité, imagine que tu développes une assemblie avec une classe qui se nommerai Class1 et une interface qui se nommerai Interface1 dans laquelle tu déclare par exemple une méthode qui vérifie d'abord si le fichier existe avant de l'ouvrir etc...tu fais hérité ta Class1 de Interface1 alors le développeur qui utilisera ton assemblie sera obligé d'implémenter les méthodes déclarer dans ton interface ainsi tu t'assures d'un "standard" d'utilisation qui sécuriserai l'utilisation de ton assemblie. j'espère avoir été clair, les spécialistes du forum reprendront mon exemple si j'ai dis une bétise ;)
Capitaine Kirk.
:mrgreen:
merci kapitaine !
je crois que je suis un peu satisfait maintenant
si j'ai bien compri, soit l'interface IStandardWindow qui désigne une fenètre windows standard, si on déclare dans cette inteface les membre suivants:
- Restaurer()
- Réduire()
- Fermer()
comme ça une classe qui veut se définir comme une fenêtre standard en passant par notre interface doit obligatoirement remplir ces trois membres!!
:king:
Bonjour,
Je ne voudrais pas insister trop, mais la réponse de Capitaine, ne donne qu'un des aspects des avantages de l'interface.
J'avais beaucoup de mal à comprendre l'utilité des interfaces, jusqu'à ce que je les utilise. Je pense que l'exemple de SaumonAgile est le plus frappant dans l'utilité de l'interface pour rendre un code plus facile à maintenir.
Tu peux aussi faire un tour du côté des designs patterns (un bon livre : "tête la première dans les designs patterns") où elles sont souvent implémentées.
Tu trouveras un exemple d'une pattern courante sur le site de developpez.com, c'est Model-View-Controler et son dérivé Model-View-Presenter. Le tutoriel montre parfaitement l'utilité des interfaces dans l'aspect "ajout d'abstraction" pour limiter un maximum les modifications risquées et couteuses de code lors des changements.
[EDIT]
Voici un lien qui illustre bien les explications de SaumonAgile
http://lowrymedia.com/blogs/technica...crete-classes/
[/EDIT]