Quelle difference existe t'il entre les interfaces et les classe abstraite en C#
Version imprimable
Quelle difference existe t'il entre les interfaces et les classe abstraite en C#
Dans ta classe abstraite il peut y avoir des fonctions/méthodes avec une implémentation. Tu peux également avoir des variables(fields), alors que les interfaces ne peuvent avoir que des propriétés.
Tu ne peux hériter que d'une seule classe abstraite, alors qu'avec les interfaces non.
Une classe abstraite et un interface proposent des contrats que toute classe dérivant de la classe abstraite ou implémentant l'interface doit respecter. Une classe abstraite comme un interface ne peut être instanciée.
Les différences sont les suivantes :
- une classe abstraite est définie avec le mot clef abstract.
- les contrats (méthodes et propriétés sans implémentations) d'une classe abstraite sont définis avec le mot clef abstract.
- une classe abstraite peut contenir des implémentations de méthodes et de propriétés.
- une classe abstraite peut contenir des champs
- une classe abstraite peut contenir comme toute autre classe des membres statiques
Peut-être qu'il y a d'autres différences mais je pense que j'ai fourni les principales. :ccool:
Une classes abstraite définit en tout ou en partie la nature d'une entité alors qu'une interface en définit plutôt la signature, la forme publique qu'elle présente aux modules en interaction.
On dit qu'une classe hérite d'une classe abstraite alors qu'une classe implémente une interface.
En d'autre mots, une classe acquière le comportement d'une classe abstraite alors qu'elle adhère au contrat d'une interface.
L'avantage des interfaces? La possibilité de définir plusieurs interfaces et d'y faire adhérer une classe ce qui permet à des consommateurs une flexibilité que ne permettrait pas l'héritage.
Je pourrais par exemple définir une méthode générique qui n'accepte que les types qui adhèrent aux contrat IDisposable et ICloneable afin de pouvoir prendre avantage de la programmation parallèle.
Les classes abstraites sont aussi un poil plus rapides, pour ceux qui veulent optimiser à mort :)
Pour moi c'est les mots hériter, et implémenter(un comportement) qui sont important pour choisir entre les deux.
Même si les détails techniques sont importants, la philosophie qui se cache derriere le concepte d'interface et d'heritage sont des notions différentes.
un humain hérite de mamifère, qui herite d'être vivant.
un être humain implemente des fonctionalité "Parler",
un mamifère implemente "Allaiter", "Se deplacer"
et être vivant "Se nourir"
Donc j'ai mis un +1 Babyneedle car il n'y à pas que les limitations techniques (qui en plus pour le multi-héritage sont des limitations technique du .Net) qui sont importantes.
part contre je n'ai pas mis de -1 a micka
Bon comme l'a dit Babyneedle, son message est en complément au mien. Et c'est ce que j'ai compris et c'est pour cela je lui ai mis :plusser: D'autre part il est bien vrai que mon message suit juste celui de micka132 mais cela ne veut pas dire que je l'ai mis :moinsser:
Comme l'a dit ClaudeBg
Donc SVP arrêtons de polluer ce thread avec ces trucs qui ne rapportent rien sur le problème posé par le créateur du thread à qui je dis que si il avait fait une recherche sur le forum il verra que le problème a été traité et retraité plusieurs fois.Citation:
Pour moi, il faut ignorer ces cotations anonymes et te fier plutôt aux commentaires placés ou non en réaction à tes interventions, ça donne une bien meilleure idée de ce que pensent les internautes.
Sinon je ne suis pas totalement d'accords avec
Pourquoi ? Parce que cela ne fait que la distinction entre une classe (qu'elle soit abstract, sealed etc...) et un interface. Quand on demande la différence entre une classe abstraite et un interface je ne suis pas d’accords que les mots hériter et implémenter soient les plus importants pour effectuer un choix.
J'arrive sur la discussion un peu par hasard, je ne suis donc pas à l'origine des + et -. Cependant, je note effectivement un truc faux la dedans :
Les interfaces ne peuvent avoir que des methodes, des propriétés, des évènements et des indexeurs (il manque méthodes, évènements et indexeurs).
Ceci est une interface légale:
Code:
1
2
3
4
5
6
7 public interface IMyContract { void SayHello(); int AgeDuCapitaine { get; } event EventHandler<EventArgs> PafLeChien; string this[string key] { get; } }
Ce n'est donc pas faux c'est incomplet, il manque juste les events :roll:. edit:et les indexeurs!
Tu noteras que j'ai marqué "fonctions/méthodes" parceque la différence est bien floues et je crois être tombés sur des dizaines et des dizaines d'avis différent sur la difference.
Pour moi c'est que la méthode ne retourne rien et que la fonction oui.
En c# ca se traduit par le void pour les méthodes, mais certains pensent que ca reste une fonction [...]Du coup j'ai mis les deux!
Non. Tu confonds une méthode et une procédure.
Une méthode est une notion représentant une fonction (exécute un ensemble d'instructions et renvoie une valeur en retour) ou une procédure (exécute un ensemble d'instructions et ne renvoie rien du tout). Une procédure est forcément une méthode mais la réciproque n'est pas vraie.
C'est la notion de méthode ou opération qui est utilisée en POO et en UML. :ccool:
Effectivement je me suis trompé de terme en voulant être plus précis:aie:.
Bon de toute facons problème réglé j'utilise le terme procedure que pour la BDD:roll:.