Articles

Affichage des articles du septembre, 2008

Programmation événementielle Acte VII)

Modèle observateur dans le Framework .NET Maintenant que nous avons certaines bases sur le modèle observateur, regardons l'utilisation de ce modèle dans le framework .NET. Pour ceux familier avec la FCL, auront sans doute remarqué que les types IObserver , IObservable , ou ObservableImpl ne sont pas présents dans le Framework. La raison première de leur absence vient du fait que la CLR les rend d'une certaine manière obsolète. Bien que vous puissiez utiliser ces constructions dans une application .NET, l'introduction des délégués (delegate) et des évènements (event), fournit un nouveau moyen très puissant pour l'implémentation du modèle Observateur sans être obligé de lui créer des types dédiés. En fait, comme les délégués et les évènements sont des classes de base de la CLR, les fondations de ce modèle se retrouvent incorporées dans le cœur du Framework .NET. La structure de la FCL en est un parfait exemple, car elle utilise le modèle observateur intensivement.

Programmation événementielle Actes VI)

Le premier argument appelé sender  permet à l'abonné de l'événement de connaître précisément l'instance de l'objet qui a émis l'événement. A quoi cela peut-il servir me direz-vous ? Et bien imaginons un instant que je possède deux instances d'un même objet, Instance1 et Instance2 , et que je souhaite m'abonner à l'événement NouveauButPourLOM . Comme dans mon cas le traitement que j'ai à faire dans cet événement côté abonné est identique pour les deux instances, je me dis que cela serait sympa de n'utiliser qu'une seule et même  méthode pour traiter les deux événements. Et bien l'argument sender m'a justement me permettre de savoir si l'événement a été émis par Instance1 ou Instance2 . A noter que si nous décidions que notre méthode CopieFichier était statique ( static ), ce premier argument n'aurait pas de sens et ne figurerait pas dans la signature. Généralement, l'événement émis par une classe à destination d