GuybrushSi ce code n'est pas bon, je ne vois pas à quoi peuvent bien servir les interfaces en C#...

Test unitaires: Mock
Injection de dépendance, etc.

GuybrushTu veux dire que dans ton exemple, (new Foo()).doSomething(); affichera "a" et non pas "b" ?

Non:

Foo fooImpl = new Foo();
fooImpl.DoSomething() => "b";
IFoo fooInterf = new Foo();
fooInterf.DoSomething() => "a";

GuybrushOu (mais "aussi pire" à mes yeux) que si x.doSomething(); est appelé, si la référence de x est stockée dans un type Foo, j'ai "b", et si x pointe vers un Foo mais stocké dans un type IFoo, j'ai "a" ?

Voila c'est ça.
Mais c'est une question de visibilité. L'interface est publique mais l'implémentation est privée ou interne, c'est donc l'interface qui gagne.
Exemple:
J'ai une interface ISourceControlServer, qui définit certaines méthodes : Get, Checkin, Edit, Merge, Branch, etc. Et j'aurai plusieurs implémentation différentes pour Git, Subversion, TFS. Tu passes par une Factory qui te renvoie l'implémentation en fonction du serveur en face, mais la classe peut être privée:

private class GitSourceControlServer : ISourceControlServer {
...
}

Et pour t'amuser, tu peux déclarer les méthodes aussi privées :

private class GitSourceControlServer : ISourceControlServer {
private bool ISourceControlServer.Checkin() { ... }
}

Après dans tous les projets, il y a des normes de codage et tu fais des codes reviews pour que tout le monde code plus ou moins identiquement, tu évites de faire dériver tes classes x fois d'une classe abstraite, tu préfères implémenter plusieurs interfaces que tout mettre dans la même, tu essayes de suivre les bonnes pratiques du Clean Code, etc.
- POLS, Principle of Least Surprise
- DRY, Don’t Repeat Yourself
- YAGNI, You Ain’t Gonna Need It
- KISS, Keep it small and simple
- SRP, Single Responsibility Principle
- CoC, Convention over Configuration
- LoD, Law of Demeter

MerlePour manipuler tout ! collections, XML, entities, ... (ce sont des implémentations différentes à chaque fois, respectivement linq2objects, linq2xml, linq2entities)

Oui, je connais un peu Linq (je ne l'ai utilisé qu'une fois par contre), mais tu disais que tu ne pourrais plus t'en passer. Je doute que tu fasses un usage quotidien de collections XML, relationnelles, etc., non ?

PetitCalgonTest unitaires: Mock
Injection de dépendance, etc.

Je pense plutôt que mon code est bon

GuybrushJe doute que tu fasses un usage quotidien de collections XML, relationnelles, etc., non ?

En fait on peut utiliser Linq sur n'importe quelle énumération. Tout ce qui hérite de IEnumerable peut utiliser Linq. Donc, les array, les collection, les listes, les dictionnaires, etc.
Ca permet de faire ce genre d'appel:
int age = Animals.OfType<Cat>().Where(cat => cat.Pounds > 100 && cat.Color == Red).First().Select(cat => cat.Age);

En 1 ligne relativement simple à lire, tu as une sélection complexe.
Et ce genre de sélection, tu en utilises tous les jours, à tout bout de champs.

Pour les personnes connectés du minichat, tu aurais:

foreach(User user in Users.Where(user => user.IsConnected)) {
...
}

PetitCalgonCa permet de faire ce genre d'appel:
int age = Animals.OfType<Cat>().Where(cat => cat.Pounds > 100 && cat.Color == Red).First().Select(cat => cat.Age);

[cat.age for cat in animals where isinstance(cat, Cat) and cat.pounds > 100 and cat.color == 'red'].pop(0)

PetitCalgonPour les personnes connectés du minichat, tu aurais:

foreach(User user in Users.Where(user => user.IsConnected)) {
...
}

for user in filter(lambda u: u.isConnected(), users):
   ...

Et visiblement, pour Python, les compréhensions de listes et l'approche fonctionnelle n'ont pas suffit à certains qui ont implémenté Pynq. Pas sûr que ça contienne énormément de providers différents

Ca veut dire qu'on a les mêmes choses géniales dans les 2 langages
Note que la notation Linq peut aussi se faire comme ca:

var query = from Animals.OfType<Cat>
            where cat.Pounds > 100 && cat.Color == Red
            select cat.Age;

Il faudra encore exécuter la query pour récupérer le 1er élément.
Et ces notations sont compatibles avec LinqToSql qui écrira et exécutera la requête SQL comme indiquée

GuybrushOui, je connais un peu Linq (je ne l'ai utilisé qu'une fois par contre), mais tu disais que tu ne pourrais plus t'en passer. Je doute que tu fasses un usage quotidien de collections XML, relationnelles, etc., non ?

Oh si, comme le dit PetitCalgon je l'utilise beaucoup sur les collections, mais également sur Entities (on a des projets qui utilisent EntityFramework).

J'ai juste une question con : quand vous avez mentionné linqpad, je connaissait pas, je suis allé voir ce que c'était. Or visiblement, si je comprend bien, linq est plus que juste linqpad. ma question persiste : www.linqpad.net/ : en gros on t'explique que tu peux utiliser naturellement SQL Server (plusieurs versions), Oracle, SQLite et MySQL ... c'est la liste exhaustive ? Non, shais pas, il me semble manquer des trucs dans la liste, des très gros, et si l'optique est strictement "pro", le lite est un peu ubuesque dans la liste. Il existe des tonnes de SGBD, le SQL est justement plus ou moins standardisé autour (plus ou moins), du coup cette liste est étrange, surtout quand on omet postgres (mais y'a pas que lui qui manque à la liste). Qui est quand même plus proche d'oracle que de sqlite.

Après, je connais absolument pas l'écosystème C# et encore moins Linq. Et je suis de la vieille école, qui tape encore du SQL au lieu de passer par des abstrateurs SQL (et encore, a minima, j'en connais autour de moi qui font quasiment des applis en SQL, je refuse de m'approcher de ces trucs tellement ça fait mal à la tête rien qu'à y penser)

Tchouc'est la liste exhaustive ?

Ça fait un bout de temps que je ne me suis plus intéressé au sujet. On avait cherché dans mon ancien boulot car on était partit sur une approche LinqToSQL / EntityFramework.
A l'époque, si je ne dis pas de bêtises, Microsoft avait fait son driver/DLL pour Linq/MS SQL et attendait des autres entreprises (Oracle, etc.) qu'ils fassent leur driver/DLL pour Linq/leur BDD.
Où est-ce que ça en est aujourd'hui, je serai bien incapable de te répondre.

Donc, soit tu trouves une DLL pour ta base de donnée qui supporte EntityFramework et t'es compatible, soit non.

A l'époque (3 ans environ) ça marchait très bien avec du MS SQL (logique) et moins bien avec d'autres BDD, elles ne savaient pas tout faire.

LinqPad, c'est juste un outil fait par un gars, qui permet (principalement) de taper des bouts de code .Net pour les tester, et de débugger facilement des requêtes linq (l'affichage des résultats de la commande Dump() est juste parfait !).

Ça n'a rien à voir avec le framework .net ou linq directement.

Linq ça veut tout simplement dire "Language Integrated Query. C'est un ensemble de méthodes mises en place par Microsoft (au départ) pour faciliter l'accès à certains types d'objets.
Tu as plusieurs implémentation de base faites par MS:
- Linq2objects: qui permet de faire des opérations sur des collections
- Linq2XML: qui permet... ben de faire la même chose mais sur des fichiers XML (plus besoin de xpath !!!)
- Linq2SQL: qui transforme ta requête linq en SQL (mais qui n'est plus supporté à l'heure actuelle, car remplacé par...)
- Linq2Entities: qui fait la même chose que Linq2SQL, mais en beaucoup mieux !

Linq2Entities fait partie d'EntityFramework (EF), l'ORM made-in Microsoft pour le .Net.

Et c'est là que la beauté opère, c'est qu'EF est database-agnostic, c'est-à-dire que tu peux le connecter sur m'importe quelle base de données, tant qu'il existe un connecteur (et il en existe des tonnes: DB2, PostgreSql, MySQL, Access,...).

Donc je dirais que les limitations dans LinqPad sont liées directement à LinqPad, pas à .Net (via EF).

PetitCalgonA l'époque, si je ne dis pas de bêtises, Microsoft avait fait son driver/DLL pour Linq/MS SQL et attendait des autres entreprises (Oracle, etc.) qu'ils fassent leur driver/DLL pour Linq/leur BDD.

C'était du temps de Linq2SQL, qui était exclusif à Sql Server. Ils ont livré ça en attendant de pouvoir livrer Entity Framework.