Discussion :

[isarian]

Voila dans mon apprentissage du C# je suis tombé sur la notion de delegate et ma recheche m'amene a ceci

http://msdn2.microsoft.com/fr-fr/lib...,printer).aspx

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
using System;
// Declare delegate -- defines required signature:
delegate void SampleDelegate(string message);
 
class MainClass
{
    // Regular method that matches signature:
    static void SampleDelegateMethod(string message)
    {
        Console.WriteLine(message);
    }
 
    static void Main()
    {
        // Instantiate delegate with named method:
        SampleDelegate d1 = SampleDelegateMethod;
        // Instantiate delegate with anonymous method:
        SampleDelegate d2 = delegate(string message)
        { 
            Console.WriteLine(message); 
        };
 
        // Invoke delegate d1:
        d1("Hello");
        // Invoke delegate d2:
        d2(" World");
    }
}

VOila je ne comprend pas trop l'utilisation de Delegate, quelqu'un aurait la gentillesse de m'expliqué l'utilité de delegate dans ce cas ci?

[varod]

La notion de délégué est un peu abstraite, le cas le plus simple à comprendre est l'utilisation comme méthode anonyme comme dans le cas de d2.
Ici d2, est définit sans que tu es besoin d'écrire une méthode externe. Attention, à ne pas abuser de cette notation, c'est plus rapide à écrire mais rend moins lisible le code. On l'utilise souvent pour des méthodes très simples.

Ensuite, il y a une utilisation de type signature. Tu connais la signature de la méthode à exécuter par contre, tu ne sais pas comment elle sera implémentée. C'est un peu le cas pour gérer les évènements (mm si ce n'est pas tout a fait la mm chose). Tu sais que lorsque tu clickes sur un bouton, tu vas appeler une méthode avec une signature (object sender, EventArgs e), par contre, microsoft ne sait pas comment tu implémenteras le click du bouton. De ce fait, dans ton code tu définis une méthode qui implémentes le click du bouton. C'est le cas de d1 dans ton exemple.

En espérant avoir été clair.

[isarian]

Clair oui tu l'as été mais je ne vois pas l'utilité, je ne vois pas d'exemple qui Nécessiterait l'emploie d'un delegate.

Quelqu'un aurait un exemple ? (pas besoin d'un code) de pourquoi il utilise un delegate?

Merci d'avance

[SaumonAgile]

La définition officielle d'un delegate est un objet qui contient une référence vers une méthode.

On utilise des delegates pour l'invocation de méthodes et pour ajouter des handlers sur des événements (entre autres).

[isarian]

Donc si je comprends bien, dans le programme on sait qu'on a une méthode X sans savoir exactement ce qu'elle fait ou autre, donc on utilise le delegate qui appelera la méthode.

[SaumonAgile]

Donc si je comprends bien, dans le programme on sait qu'on a une méthode X sans savoir exactement ce qu'elle fait ou autre, donc on utilise le delegate qui appelera la méthode.

C'est un peu l'idée effectivement.

[isarian]

TU en as deja beaucoup utilisé, des delegate?

[SaumonAgile]

TU en as deja beaucoup utilisé, des delegate?

Plus que tu ne peux l'imaginer
Et comme je suis formateur .NET, c'est aussi mon boulot d'expliquer ce que sont les delegate.
En général, pour expliquer, je fais un parallèle entre un Delegate et un Object.
De la même manière qu'un Object stocke une référence vers n'importe quel objet sans savoir de quel type est l'objet, un Delegate stocke une référence vers une méthode.
Après il est possible de définir des nouveaux types de delegate pour ne stocker que des références vers des méthodes spécifiques.

[ced600]

Enfin mais vous oubliez toute la force des delegate non ?

L'intérêt du delegate n'est pas de représenté une méthode avec une définition mais TOUTES les méthodes possédant cette définition et ajoutés au Delegate.

C'est pour cela qu'on l'utilise pour les événements windows.

Imagine toi un instant que tu crée un événement "Reception d'un mail", et que celui-ci est déclenché lorsque ton application reçois un mail ou un message.
Tu as dans ton programme trois action à effectuer lors de la réception d'un mail, et c'est trois actions sont faites par trois méthodes de trois classes différentes.
Pour des raisons de conception, tes trois classes ne se connaissent et même ne doivent absolument pas se connaitre.
Bref il manque un liens entre la réception de l'événement et le déclenchement des méthodes.
Bah le Delegate va faire le liens.

Tu va définir un Delegate associé à l'événement "Reception d'un mail", et tu vas dires dans le constructeur de tes trois classes, pour chacune d'entre elles que tu associes une de leur méthodes aux Delegate.
Donc tu te retrouve avec un Delegate pour un événement précis et trois méthodes associés à celui-ci
L'événement ce déclenche, il va du coup dire au Delegate associé de faire sont boulot, et du coup celui-ci va invoqué un à un les méthodes qui lui sont associées.

Voilà en gros le fonctionnement des événements Windows et la puissance des Delegate.

[SaumonAgile]

Enfin mais vous oubliez toute la force des delegate non ?

Non, mais après libre à toi d'apporter ta pierre à l'édifice en parlant d'un type spécifique de delegate appelé MulticastDelegate.

[isarian]

Donc ced600 si je comprend bien ton exemple le code du programme sera du style

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
 
Delegate machin
 
Class A
  methode A1
 lien delegate]
class B
  methode B1
 lien delegate
Class C
  methode C1
 lien delegate
 
Class principale
 methode main
   appel delegate

Merci j'ai compris ton exemple reste plus qu'a savoir le codé ^^

[ced600]

Un truc comme cela :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
public static event DelegueCreerLog CreerLog;
public delegate void DelegueCreerLog(string contenu);

De telle manière que le delegue soit visible par tes classes qui sont concernés par l'événement.

Et puis dans le constructeur de la classe tu peux faire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

CreerLog+= new DelegueCreerLog(MaMethode);

Et la méthode de la classe :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
public void MaMethode(string contenu)
{
}

Non, mais après libre à toi d'apporter ta pierre à l'édifice en parlant d'un type spécifique de delegate appelé MulticastDelegate

Bah mes formateurs en .Net ont expliqués les Delegate en commençant par cela

[isarian]

merci beaucoup c'est deja nettement plus clair.

Auriez vous des bons document liens ou autre pour des debutant qui s'auto forme en c#?

[ced600]

Tous les tutoriaux de developpez.com ?

[isarian]

oky merci (si il y en a d'autre je suis toujours preneur ) merci

[cinemania]

tu seras amené à utiliser les delegates quand tu sera amener à programmer des objets "réutilisables" n'importe ou sans devoir refaire le code à chaque fois pour telle ou telle circonstance.

Si ton prog est simple et qu'il se contente d'utiliser des librairies de fonctions, a moins d'avoir recours aux méthodes anonymes il y a fort à parier que tu n'ai jamais besoin des delegates.
Si en revanche ton prog contient une grosse boite à outils comme c'est mon cas, toute ma boite à outil est fondée en grande partie sur les delegate.

Quand tu fait un composant réutilisable comme Microsoft a fait dans le framewok, tu ne peux pas dire pour ce client là j'appelerais telle méthode, tu laisse donc le choix au client de ton "composant" de définir la méthode à appeler.
Toi tu est bien incapable de le savoir avant, à moins d'être devin, mais comme le compilateur lui n'est pas devin, il te diras sa façon de penser...

Si tu créer une classe qui génere un évenement, typiquement une classe réseau qui vient de recevoir un message, il se peut que plusieurs parties de ton programme soit abonnéss à cet évenement, et il se peut même que ces parties ne soient pa les mêmes à chaque instant, on utilisera donc les delegate...

Cette notion de delegate existait (en un peu moins puissante) sous C++ builder ou Delphi depuis les débuts, mais manquait (et manque toujours) au C++ traditionnel (hormi C++/CLI donc).

[isarian]

Merci ca parait plus clair grace à vous.

[ced600]

Cette notion de delegate existait (en un peu moins puissante) sous C++ builder ou Delphi depuis les débuts, mais manquait (et manque toujours) au C++ traditionnel (hormi C++/CLI donc).

D'ailleurs c'est pour cela que cela s'est retrouver dans le framework, puisque le concepteur du framework et celui de delphi sont la même est unique personne.
Désolé mais quand vous avez un prof de C# qui est un fana de delphi et qu'il vous répéte cela sans arret, bah vous commencez à faire la même chose

[SaumonAgile]

le concepteur du framework et celui de delphi sont la même est unique personne.

Voila une vision tout à fait intéressante de la conception du framework... Conçu par une personne... Un des concepteurs de Delphi a sans doute participé à la conception, mais sûrement pas une seule personne pour tout concevoir.

Sachant au passage que le point central du framework est une seule et unique fonctionnalité, le CAS. Tout le framework est architecturé autour de ce concept et aucun autre.

[ced600]

Voila une vision tout à fait intéressante de la conception du framework... Conçu par une personne... Un des concepteurs de Delphi a sans doute participé à la conception, mais sûrement pas une seule personne pour tout concevoir.

Ils ont été plusieurs pour ce porjet, mais MS à quand même acheté le papa de Delphi (offre d'emplois avec très haut salaire, et grosse liberté sur l'implémentation du c#).
Et oui je me suis trompé il n'a pas principalement travaillé sur le framework (un peu je crois), mais sur le J++, WFC, et le C# :

In 1996, Hejlsberg left Borland and joined archrival Microsoft. One of his first achievements was the J++ programming language and the Windows Foundation Classes; he also became a Microsoft Distinguished Engineer and Technical Fellow. Since 2000, he has been the lead architect of the team developing the C# programming language.

Voir Wiki.

Pour cela qu'il y a une grosse ressemblance entre le C# et le Delphi. Mon professeur à l'époque me disait qu'en C# il y a des trucs qu'il n'avait pas pu faire à Borland.