Comment utilser le default comparer dans une liste ?

Bonjour

J'ai constitué une liste composée d'elements (classes) contenant 2 int et un string

Je veux trier cette liste sur le premier int de la classe
Dois-je absolument definir un comparer pour cela ou le default comparer peut etre utilisé d'une maniere ou une autre.

Dans le cas contraire, a quoi sert le default comparer ?

Merci pour votre aide

Le "default comparer" obtenu via Comparer<T>.Default (utilisé par List quand tu ne lui en fournis pas un explicitement) nécessite que ta classe T implémente IComparable<T> ou IComparable à défaut.

Donc si tu implémentes l'une de ces deux interfaces sur la classe contenue dans ta liste pour fournir une comparaison basée uniquement sur ton premier entier, tu n'auras pas à fournir de comparateur à ta liste.

Cette implémentation fournira de fait le comparateur par défaut pour ta classe, ce qui n'empêchera pas d'en fournir un autre suivant tes besoins à l'occasion, mais de manière explicite.

Par exemple, le comparateur par défaut du type Int32 doit les trier dans l'ordre croissant, mais rien n'empêcherai de fournir un comparateur qui les trierait dans l'ordre inverse, qu'il faudrait alors indiquer à la liste.

Merci

Citation:

---

Donc si tu implémentes l'une de ces deux interfaces sur la classe contenue dans ta liste pour fournir une comparaison basée uniquement sur ton premier entier, tu n'auras pas à fournir de comparateur à ta liste.

---

Pour ca je ne sais pas bien ce qu'il faut faire et je n'ai pas encore manipulé des types interface (je dois encore apprendre ca)


Finalement un bon comparer fait maison c'est sans doute le plus simple et le plus explicite

Citation:

---

Envoyé par olibara

Merci


Pour ca je ne sais pas bien ce qu'il faut faire et je n'ai pas encore manipulé des types interface (je dois encore apprendre ca)


Finalement un bon comparer fait maison c'est sans doute le plus simple et le plus explicite

---

Justement, ce serait l'occasion d'apprendre à utiliser les interfaces. Ce n'est pas difficile à comprendre, et c'est un concept très puissant. En simplifiant un peu, implémenter une classe revient à hériter d'une classe abstraite, à 2 différences près :
- tu peux implémenter plusieurs interfaces, alors que tu ne peux hériter que d'une seule classe
- une interface ne contient aucun code, seulement les déclarations des méthodes et propriétés (alors qu'une classe abstraite peut avoir des méthodes non-abstraites)
Pour les détails => voir les cours ou la doc...

En fait, je pense qu'il faut implémenter IComparable pour définir l'ordre de tri "naturel" pour ce type (et c'est l'ordre qui sera utilisé par défaut). Pour trier d'une façon plus spécifique, tu utilises un Comparer.

Merci je vais piocher un peu les interfaces !

Citation:

---

Envoyé par olibara

Merci je vais piocher un peu les interfaces !

---

Si tu comptes faire un développement un tantinet sérieux, c'est en effet quelque chose à investiguer d'urgence...

Peut-être devrais-tu te familiariser avec les concepts de base du langage dans un premier temps, parce que les interfaces c'est plutôt au tout début :P. Une fois le langage appréhendé, tu pourras explorer l'API offerte par le framework beaucoup plus sereinement.

Merci Greybird

???

J'ai déja fait trois applications tres sérieuses et tres complete et pour aucunes de ces trois je n'ai eu besoin de cet animal "interface"

C'est sans doute la face cachée de la lune que je ne connais pas encore et qui recelle des trésors conceptuels inexploités. Mais ca ne m'a pas empeché d'avancer jusqu'ici.

Si tu connais un lien vers un tuto bien fait, j'achete

Salut Graybird

Oui j'investigue un peu et si je comprends bien le concept d'interface, c'est pour ajouter une couche d'abstraction complémentaire entre l'intention d'une methode et son codage

Mais il ne me semble pas que l'usage des interface soit particulierement répandu et populaire ... ?

Tout ADO.Net est basé dessus, et dès qu'on bosse sur les collections, c'est quand même bien pratique d'avoir une fonction qui prend juste un IEnumerable<T> en paramètre parce qu'elle ne fait rien d'autre que parcourir un paramètre séquentiellement. Exemple bidon :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

int Somme(IEnumerable<int> source) { int result = 0; foreach(int i in source) // seul le fait que source soit énumérable nous intéresse result += i; return result; }   int a = Somme(uneList); int b = Somme(unDico.Values); int c = Somme(unArraydEntiers); int d = Somme(uneMethodeAvecUnYieldReturnDedans());

---

Bonjour,

Cette discussion sur les interfaces m'a fait prendre conscience que je sais très bien ce qu'est une interface, mais que je ne sais pas du tout quand l'utiliser.

Ma question, plus concrètement est:
Partons du principe que je suis en phase de conception, le nez dans les diagrammes UML.
Quand dois-je me dire: tiens là il faut que j'utilise une interface ?

Actuellement, je pense être incapable d'intégrer les interfaces dans une conception.
Je n'ai pas trouvé de réponse claire à ce sujet alors si vous pouviez avoir l'aimabilité de m'expliquer ou de m'indiquer un petit tutorial/article là dessus, je serais preneur ;)

Salut
Merci pour ta réponse et cet exemple tres clair !

Oui vu comme ca c'est effectivement fondamental et je comprends que c'est une base d'ADO.NET

Ce que je voulais dire c'est qu'il me semble qu'en général peu de developpeurs ont le reflexe d'ajouter des interface dans leur application la ou ca pourrait etre utile

Bonjour

Un lien intéressant que j'ai trouvé

http://www.codeproject.com/KB/cs/abs...nterfaces.aspx


La discussion et l'exemple portent surtout sur la distinction entre Abstact et Interfaces

Mais ca aide a assimiler les concepts

Je dirais qu'avant de créer ses interfaces, il est sain et instructif de regarder l'usage que le framework en fait déjà. Comme je disais tout à l'heure, l'ensemble des classes dans System.Collections(.Generics) implémente des tas d'interfaces, qui héritent les unes des autres, et qui permettent à l'image des iterators C++ de manipuler des "conteneurs" sans se soucier de savoir comment cela a été implémenté.
Autre exemple : en remoting, on a besoin de spécifier un canal par le quel transitent les données entre deux applis. Il y a donc une interface IChannel ; après, le framework propose un TcpChannel, un HttpChannel, et des tiers peuvent en fournir d'autres (dans mon cas IiopChannel par exemple), dont l'utilisation est identique bien que l'implémentation soit complètement différente.

Bref, mon conseil est le suivant : quand on crée une fonction prenant on objet bien connu en paramètre, il peut être intéressant de se dire "qu'est-ce que j'utilise vraiment de cet objet ?" afin de rendre très simplement cette méthode très générale. Dans mon exemple de tout à l'heure, on ne cherche qu'à itérer ; un ienumerable suffit. Si on avait besoin de la taille de la collection, un ICollection<T> conviendrait mieux.

Pour ADO.Net, un article de SaumonAgile explique très bien cela. Plutôt que coller en dur que l'on bosse avec un OracleParameter, un OracleConnection, un OracleCommand, etc., on peut déclarer des variables comme des IDbParameter, des IDbCommand, etc., ce qui permet de passer d'une bibliothèque d'accès aux données à une autre très facilement si besoin.

Pour BigFoot69

Un autre lien en anglais mais intéressant

http://www.brainbell.com/tutors/C_Sh...erface_Use.htm

Merci Guulh

Tres bel exposé et tres clair !

Merci olibara, je vais jeter un coup d'oeil ;)