[Article] Introduction aux délégués en C#

Bonjour,

Vous pouvez poster dans cette discussion vos commentaires concernant l'article Introduction aux délégués en C#.

Merci à tous.

Salut,

Soit j'ai pas bien dormis, soit je me endormis le 8/11/2010 et me suis réveillé 9 jours après. La date de publication ne me parait pas correcte : 17/11/2010 alors qu'on est le 9/11/2010 aujourd'hui.

Bon concernant le tuto, j'ai pas encore tout lu. Mais la structuration, l'agencement du tuto et surtout avec des bouts de code à chaque 5-10 lignes de lecture permet de ne pas rester trop dans la théorie et donne envie de continuer jusqu'au bout.

Je ferais un retour global sur le contenu quand j'aurais terminé de tout lire.

Dans tous les cas merci pour le tuto.

Citation:

---

Envoyé par h2s84

Soit j'ai pas bien dormis, soit je me endormis le 8/11/2010 et me suis réveillé 9 jours après. La date de publication ne me parait pas correcte : 17/11/2010 alors qu'on est le 9/11/2010 aujourd'hui.

---

C'est juste que Philippe Vialatte m'a déjà fait savoir que l'article serait officiellement publié le 17, donc...

Effectivement publié le 17, comme prévu.

Très bon tuto sur un sujet que je connais très peu (enfin je croyais connaitre peu, mais je me rend compte que je ne connais finalement pas du tout).

Ok pour le délégué, jusqu'au évènements, par contre à partir des expression Lamda, je suis largué.

Comme dit la conclusion, ça permet d'avoir "code plus compact, en simplifiant de nombreuses opérations qui seraient autrement bien plus verbeuses. "
Mais comme bien souvent, compactification et simplification se fait au détriment de la lisibilité et de la compréhensibilité du code. Et même étant pro du C#, si on est pas pointu sur les lamdas, Func, etc ... on a pas fini de galère à relire un code qui les utilise largement.

Je suis prêt à adopter les délégués (qui m'auraient déjà bien servis si j'en avait connu toute la puissance) et les méthodes anonymes. Par contre, les lamdas, je crois que je vais les laisser dans le placard encore un petit moment.
Je préfère écrire 10 lignes de codes claires à la première lecture, qu'une seule qui nécessite plusieurs minutes de déchiffrement

En fait si tu utilises Linq, Entity ou certains types de listes ou tableaux , tu dois déjà utiliser les expressions lambdas.
C'est marrant parce que moi venant d'un langage dynamique , c'est la première chose que j'ai cherché à faire dans C#.
Par contre j'ai eut du mal avec les génériques.
C'est un peu pour cela que j'aurai aimé utilisé JScript.NET plutot , mais il n'a pas de delegates.

Citation:

---

Envoyé par sevyc64

Et même étant pro du C#, si on est pas pointu sur les lamdas, Func, etc ... on a pas fini de galère à relire un code qui les utilise largement.

---

Oui mais pour être pointu, faut déjà commencer par l'utiliser...
Les lambdas ne sont pas plus complexes que d'autres concepts inclus dans C# depuis longtemps (POO de base, generics, class vs struct, yield, ...) Comme toutes fonctionnalités, elles risquent d'être trop/mal utilisées par des développeurs débutants.
Pour certains scénarios, spécifiques mais courant, c'est quand même nettement plus lisible. Je regardais un tuto posté sur dvp récemment, sur l'utilisation des google-collections en java:

Code:

---

1 2 3 4 5 6 7

List<Personne> result = newArrayList(Iterables.filter(personnes, new Predicate<Personne>() { public boolean apply(Personne personne) { return personne.isHomme(); } }));

---

Qui se traduit en C# par

Code:

---

var result = personnes.Where(p => p.IsHomme);

---

C# (pas autant que C++ certes) est multi paradigme, faut s'y faire :)

Citation:

---

Envoyé par sevyc64

Et même étant pro du C#, si on est pas pointu sur les lamdas, Func, etc ...

---

Désolé, mais les deux membres de la phrase me semblent un peu antinomiques. :P

Citation:

---

Envoyé par Bluedeep

Désolé, mais les deux membres de la phrase me semblent un peu antinomiques. :P

---

NON !!!

On peut être pro sans forcément obligatoirement tout connaitre sur le bout des doigts

C'est d'ailleurs pour ça qu'il existe des formations complémentaires ou même des tutos comme celui sujet de ce fils.

Citation:

---

Envoyé par sevyc64

NON !!!

On peut être pro sans forcément obligatoirement tout connaitre sur le bout des doigts

---

Certes oui, mais vu que LINQ est l'un des gros morceaux de .Net 3.5 qui a plus de deux ans, et qu'il est utilisable sur tout type de projet (par opposition à WPF ou WCF qui remplacent leurs prédécesseurs respectifs et ne peuvent être abordés à la légère), il est très recommandé de s'y intéresser.
Je suis d'accord que pour C++, qui propose des tas des features (il est fait pour ça) orthogonales les unes aux autres, on peut s'interdire d'utiliser telle ou telle fonctionnalité (surcharge d'opérateurs, héritage multiple, ...) dans un projet pour en faciliter la compréhension et limiter les risques de mauvaise utilisation. Mais je ne pense pas que linq et les lambdas soient "abusables" au point de préférer s'en passer.

Pour revenir à l'article: bien fichu, rien à dire.
Un chipotage: dans la partie sur les events, il aurait peut être mieux valu se plier aux conventions de nommage usuelles.
Et donc

Code:

---

1 2 3 4 5

public delegate void TrainArrivalEventHandler(object sender, EventArgs e); public class TrainStation { public event TrainArrivalEventHandler TrainArrival; }

---

plutôt que

Code:

---

1 2 3 4 5

public delegate void TrainArrival(object sender, EventArgs e); public class TrainStation { public event TrainArrival OnTrainArrival; }

---

Citation:

---

Envoyé par Guulh

Un chipotage: dans la partie sur les events, il aurait peut être mieux valu se plier aux conventions de nommage usuelles.
Et donc

Code:

---

1 2 3 4 5

public delegate void TrainArrivalEventHandler(object sender, EventArgs e); public class TrainStation { public event TrainArrivalEventHandler TrainArrival; }

---

plutôt que

Code:

---

1 2 3 4 5

public delegate void TrainArrival(object sender, EventArgs e); public class TrainStation { public event TrainArrival OnTrainArrival; }

---

---

C'est une bonne idée. Je ferai la modif dès que j'ai 5 minutes.

Et je suis d'accord qu'on ne peut pas se qualifier de pro du C#, en tout cas à partir de la version 3.5, sans maîtriser les expressions lambda et plus généralement Linq qui est une petite merveille. Ta comparaison avec java est à ce titre assez édifiante. Linq est la feature du .NET qui enfonce Java actuellement.

Citation:

---

Envoyé par sevyc64

On peut être pro sans forcément obligatoirement tout connaitre sur le bout des doigts

---

:mouarf:

Citation:

---

Envoyé par Guulh

Certes oui, mais vu que LINQ est l'un des gros morceaux de .Net 3.5 qui a plus de deux ans, et qu'il est utilisable sur tout type de projet il est très recommandé de s'y intéresser.

---

Voulant passer la certif sur .net, j'ai regardé les bouquins M$ de la librairie Eyrolles, à Paris; Ah Ah des livres M$ "officiels" sur Windows serveur 2008 et ... .net 2 :aie:

oui mais les certifications c'est vaste...
il y en a pléthore... et on ne se certifie pas sur un langage, mais sur une technologie particulière de dotnet...
A ce titre, tu peux choisir VB.NET ou C# lors de la certif, de façon indifférente, la seule condition étant d'en maîtriser au moins 1 des 2.

en plus les certif à proprement dit dans le développement dotnet, nécessitent minimum 2 examens, dont
le 70-536 : .NET Foundations qui est basé exclusivement sur les fondements de dotnet, et donc le framework 2.0.
A ce titre les écritures utilisées lors de l'examen sont à l'ancienne, donc sans linq, sans lamba, et généralement sans méthodes anonymes pour que la certification VB.NET et C# soient cohérentes, car les méthodes anonymes n'étaient alors pas intégrées à VB.NET. Mais avec une utilisation ou non des generics... en effet, ceci fut intégré à dotnet 2 et sont vastement utilisés de nos jours, mais quand ces examens ont été écrits, nombre en étaient encore à se battre avec les arraylist...

pour ce qui est de se prétendre pro d'un langage... c'est quelque part une hérésie ou plutôt incomplet. point de vue partagé par Microsoft s'il en est, puisqu'il n'y a pas de certification sur un langage...
en fait on parle d'un pro dans une technologie particulière, et dotnet en expose tellement qu'il est difficile d'en faire le tour...
cependant être pro dans une technologie suppose néanmoins d'être en mesure de maîtriser (pas à la perfection toutefois, car chacun à son niveau) l'outil fondamental qui est le langage employé.
de plus prétendre à être "pro" sur une technologie suppose qu'on se maintiens à jour... il est donc logique qu'on se maintiens à jour également pour le langage que l'on utilise, et qu'on apprend donc à utiliser les constructions syntaxiques qu'on risque de rencontrer partout, surtout lors de développement en équipe.

le problème c'est que nombre se prétende professionnels sur un langage et une technologie donnée... juste après avoir suivit une petite formation rapide, ou après avoir été à l'école... hors c'est généralement faux.
au sortir de ces formations ou des écoles, tu n'apprend que grossièrement le langage, par conséquent, même si on te fait voir les différentes constructions syntaxiques, et généralement tout ce qui est postérieur à dotnet 2 n'est pas enseigné, tu n'apprend pas à en maitriser toutes les subtilités...

connaitre une construction syntaxique ne signifie aucune qu'on la maitrise, ni elle ni ses subtilités, mais c'est à force de la rencontrer, par l'expérience qu'elle entre dans les mécanismes de cheminement de la pensée, et que sa lecture devient quasi automatique et aussi claire qu'une écriture plus ancienne et plus verbeuse...
j'ai souvent moins de mal à lire un code usant massivement des lambda qu'un code écrit à l'ancienne sans lambda voir sans méthodes anonymes...

je rappellerais aussi que se priver des lambda et plus généralement de leur ancêtre les méthodes anonymes c'est se priver de features quasi-indispensables dans certains scénarios comme les closures...

on ne peut pas ou qu'assez rarement maitriser un langage à la perfection.
de même maitriser dotnet de façon générale, et tout particulièrement C# 4.0 ne signifie pas non plus qu'on sera un cador dans la réflexion avancée, et tout particulièrement l'émission de code et le CIL... et les rencontrer donne des mots de tête quand on est pas habitué... mais c'est pour tout pareil.
certes c'est un exemple un peu violent... mais il résume plutôt bien la situation.
en un mot l'habitude... ce n'est qu'en les utilisant régulièrement qu'on prend l'habitude d'une construction et qu'on finie par la trouver lisible et que l'on peut alors prétendre à juste titre être un professionnel.

tu serais surpris de ce que je trouve lisible, comparé à ce que trouve lisible certains autres...
pour moi un code C# ultra compacte et condensé utilisant massivement les lamda, les méthodes d'extensions ou les écritures linq, ne me gêne pas et je trouve cela relativement lisible, dans la mesure où le code est aéré.
c'est cette même raison qui fait que selon moi, les langages trop verbeux comme VB nuisent finalement à la lisibilité, car trop de code tue le code.
je suis bien d'accord que certaines expressions sont difficilement lisible, mais entre un code de 50 lignes aérés utilisant linq, les lambdas, les generics, les anonymes, les types anonymes, ou les closures, et un code équivalent qui fait 300 lignes pour n'en apprendre pas plus sur le sujet, je ne suis pas convaincu que le code de 300 lignes, meme aéré soit plus lisible, sous prétexte que les opérateur sont clairement écrit And au lieu de & ou &&...

sinon pour le tuto ... que dire de plus... très bien...
il serait peut-être bon d'ajouter une mise en garde en ce qui concerne les évènement et les fuites mémoires dues aux délégués dans ce cas bien précis...

Je ne suis pas un fanatique des certifications, qui n'ont pour moi qu'un intérêt commercial.
La certification, à part un programme minimal n'a pas un grand intérêt technique je m'en doutais...

Citation:

---

Envoyé par cinemania

tu serais surpris de ce que je trouve lisible, comparé à ce que trouve lisible certains autres...

---

j'ai lu, il y a longtemps un cours sur le c( c++ peut être) qui disait qu'il ne fallait pas utiliser les opérateurs virgule ni ternaire (? : ).
Et j'ai constaté que beaucoup de développeurs (c, php,..) utilisaient :

Code:

---

1 2 3 4 5

if ( test ) { variable = truc; }else{ variable = autre_truc;}

---

tandis que je trouve plus clair :

Code:

---

variable = ( test ? truc : autre_truc);

---

Citation:

---

Envoyé par cinemania

je suis bien d'accord que certaines expressions sont difficilement lisible, mais entre un code de 50 lignes aérés utilisant linq, les lambdas, les generics, les anonymes, les types anonymes, ou les closures, et un code équivalent qui fait 300 lignes pour n'en apprendre pas plus sur le sujet, je ne suis pas convaincu que le code de 300 lignes,

---

Certes, mais plus on met ce genre de choses dans son code plus il est difficile de trouver des gens capables de le maintenir soit ils ne sont (et ne seront) pas compétent sur cette techno, soit ils ne la connaissent pas et ils doivent se former, soit trop cher.
Linq, c'est super je suis d'accord mais cela demande de plus en plus de connaissances ce qui pose un gros problème à mes yeux.
Lire ce qu'en pense en exemple pcaboche https://www.developpez.net/forums/showthread.php?p=5609551

Citation:

---

Envoyé par valkirys

Linq, c'est super je suis d'accord mais cela demande de plus en plus de connaissances ce qui pose un gros problème à mes yeux.
Lire ce qu'en pense en exemple pcaboche https://www.developpez.net/forums/showthread.php?p=5609551

---

L'opérateur ternaire ? : est vieux comme C (au moins), il est présent dans un paquet de langages qui s'en sont inspiré, donc faut espérer que pour un projet donné il y aura toujours au moins 1 personne qui le connait... Autrement, le projet est mort, de toutes façons...
Le sujet du nivellement vers le bas revient souvent sur le forum. A mon avis, il est important dès l'entretien pour la mission / le job de voir la technicité attendue. Est-ce qu'on cherche un code monkey capable d'accumuler les if then else que tout le monde sera capable de faire évoluer en rajoutant de nouvelles couches de if then else jusqu'à ce que mort s'ensuive, ou est-ce qu'on espère qu'il y aura toujours sur le projet au moins 1 personne un poil capable d'adapter l'architecture au fur et à mesure et de trouver le bon outil pour le besoin.

Et Linq, c'est pas dur à comprendre, et ça peut servir dans tout type d'occasions. En tous cas si y'a pas dans l'équipe au moins une personne capable de l'appréhender et de partager sa science, le projet est mal barré...

bien disons que développer en C# ou du moins se prétendre développeur C#, suppose quand même qu'on en connaisse les subtilités...
pas qu'on les maitrises, mais qu'on les connaissent.

le piège des memory leaks due aux évènements, bien que très gênant, il n'est pas rare de trouver de bons développer C# qui l'ignore... ca n'en fait pas pour autant de mauvais ou moins bon développeurs.
cependant ne pas utiliser les délégates, ou les lambda, ou les expressions linq pour ceux qui préfère utiliser la forme linq que les méthodes d'extensions, ou meme de ne pas utiliser les méthodes d'extensions... ce n'est plus être développeur C#... c'est développer en C#, comme un développeur java.
La technologie en question n'a pas que l'utilité des requêtes SQL, dans la mesure où on trouve Linq To Object et Linq to XML.
Bien entendu, on ne parle pas là de WCF, qui lui est bel et bien un framework a part dont la maitrise n'est pas requise pour être un développeur C#, et qui plus est dotnet, d'autant qu'il n'apporte rien à la richesse de C#.

Pour ce qui est d'un cas plus récent, comme C# 4.0 et l'apparition des dynamic ou de la gestion de la variance... là non plus ce n'est pas extrêmement gênant pour l'instant.
Primo : les dynamic étant fortement basés sur la reflexion, leur utilisation a un cout non négligeable en ressources, et leur utilisation ne devrait être rencontrée que dans des cas bien précis.
La variance est un concept utilisé sans même s'en rendre compte quand on développe avec les generics et tout particulièrement les délégués en .NET 4.
De toute façon C# 4 ayant à peine quelques mois, ce n'est pas gênant, mais pour une technologie comme Linq qui a plus de 2 ans... il devient problématique qu'elle ne soit pas connue...
pas forcément maitrisée mais au moins connue.

Le nivellement par le bas, n'est pas et ne sera jamais une solution, sinon on continue à produire pour ses clients des produits, vieillissants, comme nous même, à l'image de notre programmation.
Être un bon développeur commence par la remise en question permanente et l'apprentissage constant.

L'encroutement des développeurs ne devraient pas être une contrainte de développement sur un projet.

je développe actuellement avec Linq, et à peu près tout l'arsenal de C#, excepté les dynamics car je préfère encore l'émission de code, nettement plus rapide (en performance, pas au développement...)
d'autres sont susceptibles de relire mes sources...
dois je absolument m'inquiéter de leur niveau ? dois je absolument être sure qu'ils aient le même niveau que moi ?
mon employeur exige de moi que je me certifie et tienne à jour sur dotnet, et donc sur VB.NET et C#... je part donc du principe qu'il est normal, que mon code reflète cet état de fait.

quand le nouveau développeur est arrivé, étant tout juste sorti d'école, je me doutais bien qu'il ne connaissait pas vraiment les nuances, et des écritures comme Linq, les lambda ou autre... j'ai donc pris sur moi de lui apprendre, afin qu'il puisse écrire un code plus clair et compact, surtout en VB.NET qui est déjà beaucoup trop verbeux.
(bon j'ai due lui apprendre VB.NET aussi car il n'avait fait que du C#, mais c'est une autre histoire)

personnellement ce que je ne supporte pas de voir car cela n'est pas plus lisible c'est :

Code:

---

1 2 3 4 5

if (a>0) val = true; else val = false;

---

qui devrais être écrit

Code:

---

1 2	val = (a>0);

---

bien qu'ici les () ne soient pas nécessaires, elles sont juste indiquées pour des raisons de lisibilité...

de plus même si en C#, cela n'a pas de cout particulier, il n'en est pas tout à fait de même en natif pour les développeurs qui reparte vers du natif en ayant conserver leurs mauvaises habitudes... et ou certaines routines critiques nécessite un minimum de soin dans les écritures.
Les développeurs de nos jours, pour ce sacrosaint nivellement par le bas, ne prennent plus la peine de réfléchir aux implications de ce qu'ils écrivent, sur l'impact sur les ressources, les temps de calculs et autres.

certes je suis d'accord tous les développeurs n'ont pas vu la calculabilité de façon approfondie dans leur cursus, pour peu qu'ils en aient un, mais, si une boite recrute, des développeurs, le mieux est de les confronter à un test pour voir s'ils sont viable ou non... comme dans toutes les sociétés où je suis entré jusqu'ici.
il est souvent juste nécessaire d'avoir un seul développeur plus qualifié que les autres, pour porter le groupe vers le haut, et pérenniser le développement.
si le but est de le remplacer, il suffit juste de vérifier que la personne conviendra, c'est déjà pour cela que les périodes d'essais existes.

bah je me contenterais de dire que cet article est super : )

Il m'aurait bien aidé quand j'avais joué avec remoting et les events, en .net1, 2.., 3? Je ne sais plus mais bon, ça commence à dater sévère.

Par ailleurs, à la lecture de l'article partie 1 et 2, j'ai pensé qu'il aurait très bien pu être adapté pour expliquer le concept des closures.
Puis ensuite spécialisé l'article pour tel ou tel langages avec ces spécificités de syntaxe et de fonctionnement.

Merci pour ce que tu nous partages ;)
Au plaisir de te relire !

a +

Citation:

---

Envoyé par cinemania

bien disons que développer en C# ou du moins se prétendre développeur C#, suppose quand même qu'on en connaisse les subtilités...
pas qu'on les maitrises, mais qu'on les connaissent.

....

---

En même temps on peut toujours faire sans linq... je pense que l'important est que le dev sache ce qu'il fait. On ne peut pas maitriser toutes les subtilités d'un langage. Func , expressions trees , delegates, extension methods , etc ... c# est quand même un langage relativement touffu... avec en plus tout le framework .NET à apprendre , sans compter toutes les nouvelles classes qui tombent régulièrement , c'est impossible de tout connaitre, rappelons que le but est de développer des applications.