POURQUOI CE BLOG, POUR QUI ?


POURQUOI CE BLOG, POUR QUI ?
Ce Blog s'adresse à tous ceux qui sont passionnés par les sciences informatiques , Professionnels,Etudiants,Amateurs ...
Les sujets exposés dans la suite se rapporteront essentiellement sur l'analyse informatique,la programmation,le développement ainsi que à l'architecture IT.
QUI SUIS JE ?
Je suis Kangulungu Lubilanji, Consultant-Freelance sur les technologies .NET,C#,ASP.NET ... Contactez moi pour plus d'informations.

La Programmation OO: Chapitre 18. Programmation évènementielle

Chapitre 18. Programmation évènementielle
Ce chapitre décrit un mode plus implicite de communication entre les objets, où chacun d'eux peut être observé par un autre, de telle manière que la modification de l'état de l'objet observé déclenche l'exécution d'une méthode chez l'objet observant, tout cela se passant sans le moindre envoi de message.


Des objets qui s'observent, Il existe un manière de penser la communication entre objets, relevant de la « programmation évènementielle », une manière plus implicite,n'utilisant pas les envois de messages, mais exigeant que les objets s'observent plutôt qu'ils ne se parlent. Il s'agit de programmer en couvrant « couvrant les derniers évènement ». Cette observation d'un objet par un autre permettra à l'observateur d'ajuster son tir en fonction de l'observé. On crée un lien de dépendance entre les objets plutôt que de communication. Ce mode de programmation sera appelé évènementiel, car une chose qui se produit dans un objet sera considéré comme un évènement pour un ensemble d'autres, qui devrons alors agir en conséquence.
Cette dépendance ne pourra être concrétisée dans aucune des deux classes concernées, l'observable et l'observateur, mais plutôt dans un troisième classe, qui établira ce lien de dépendance. Bien sûr, le mode de programmation qui  sous-tend en arrière-plan cette interaction reste l'envoi de message, mais cette couche supplémentaire, réalisée comme un des vingt-trois « design patterns », permet de penser l'interaction d'une manière différente et moins contraignante. La pratique demande très simplement, d'abord, d'une classe, qu'elle se transforme en classe observable. Ce faisant, dans la déclaration de cette classe devra figurer, à un endroit précis de son code, son  souci d'avertir tous ceux et celles qui l'observent, que s'est produit ce dont elles voulaient être informées. Ces dernières, ensuite, réagiront en conséquence. Dans leur code, effectivement, les  classes qui l'observent doivent prévoir ce qu'elles feront au moment de l'occurrence de l'évènement. Finalement, une troisième classe sera responsable de la relation s'établissant entre les observateurs et les observés, en inscrivant ceux-ci auprès de ceux-là.

En C# : les délégués 
Généralités sur les délégués dans .Net
Dans .Net, les délégués sont des référents de méthode qui  permettent de séparer dans l'écriture du code l'appel d'une méthode de son implémentation. Ils sont directement inspirés des pointeurs sur les fonctions qu'autorise C++. La définition de la méthode peut être différée par rapport  à l'appel de celle-ci à même le code. La déclaration du délégué sera conforme à la signature de toutes les méthodes cherchant à se substituer de celui-ci  lors de l'exécution. Le nom « délégué » exprime la possibilité pour ceux-ci d'être « délégué » par les véritables méthodes, le temps que celle-ci soient définies. Cela pourrait ressembler à des interfaces, mais limitées à une seule méthode. Le client ne connaissent que l'interface lors de la compilation, et la méthode ne sera trouvée et mise en oeuvre qu'au moment de l'exécution. On fait tout avec ce délégué, sauf définir son bloc d'instruction, et son association avec la méthode qui le concrétise précisément et qui se produit au moment de l'exécution. Le code C# qui suit devrait clarifier ce mécanisme :

public class TestDelegue {
        public delegate void exempleDelegue(string message);
        static void Main(string[] args)
        {
            Testeur t = new Testeur();
            exempleDelegue ed = new exempleDelegue(t.faire);
            ed("Kangulungu");
            Console.ReadLine();
        }
    }
    class Testeur
    {
        public void faire(String message) {
            Console.WriteLine("Bonjour " + message);
        }
    }
Dans ce code le délégué est d'abord déclaré comme ne pouvant s'associer qu'à des méthodes ne renvoyant rien mais recevant un String en paramètre. Ensuite, une instance du délégué ed est créée, que l'on associe à la méthode t.faire afin qu'elle soit conforme à  cette signature. On exécute ensuite le délégué comme si il s'agissait de la méthode en lui passant l'argument en question . L'exemple suivant montre qu'un même délégué peut recevoir une suite de méthodes, toutes signées de la même façon. La première méthode est non statique et exige la création d'une u-instance de la classe Testeur ; la deuxième est statique et peu fonctionner directement à partir de la classe.

public class TestDelegue {
        public delegate void exempleDelegue(string message);
        static void Main(string[] args)
        {
            Testeur t = new Testeur();
            exempleDelegue ed = new exempleDelegue(t.faire);
            ed += new exempleDelegue(Testeur.faireAutrement);
            ed("Kangulungu");
            Console.ReadLine();
        }
    }
    class Testeur
    {
        public void faire(String message) {
            Console.WriteLine("Bonjour " + message);
        }
        public static void faireAutrement(String message)
        {
            Console.WriteLine("Au revoir " + message);
        }
    }
Nous avons vu ce mécanisme à l'oeuvre lors de la mise en pratique du multithreading « à la sauce » .Net. Pour ce faire, un délégué de type ThreadStart peut s'associer à n'importe quel corps de méthode renvoyant  void et ne recevant aucun argument. Il s'agit bien du corps d'instruction associé au thread. On conçoit dès lors l'équivalence fonctionnelle des interfaces (à la java) et des délégués (à la .Net). On retrouve cette même équivalence dans la mise en oeuvre des délégués pour implémenter les fonctionnalités « bouton »
et « souris » dans .Net, comme le petit code ci-dessous l'illustre : un bouton est crée puis disposé sur une fenêtre. Lorsqu'on clique sur ce même bouton, ce qui se produit est défini par la méthode associé au délégué EventHandler.

 public partial class BasicWindowsForm : Form
    {
        protected Button bouton;
        public BasicWindowsForm()
        {
            Init();
        }
        private void Init() {
            this.Size = new Size(400, 400);
            this.Text = "Basic Windows Form";
            CreeBouton();
        }
        private void CreeBouton() {
            bouton = new Button();
            bouton.Text = "Hello Kangulungu";
            bouton.Dock = DockStyle.Fill;
            this.Controls.Add(bouton);
            bouton.Click += new EventHandler(Handler); /* l'association entre le délégué et son corps, appel sur clique du bouton */
        }
        private void Handler(object envoyeur, EventArgs e) { // implémentation du délégué
            Console.WriteLine(e.ToString() + " " + envoyeur.ToString());
            Console.WriteLine("Hello World");
        }
        public static void Main() {
            Application.Run(new BasicWindowsForm());
        }
    }

Aucun commentaire: