符合Net指南的事件有什么好处？ [英] What are the benefits of having events conforming to Net guidelines?

问题描述

我了解如何根据Net Framework指南使用事件，但使用此模式有什么好处？

http://msdn.microsoft.com/en-us/library/aa645739%28VS.71% 29.aspx ：

.NET Framework准则指出，使用
的代理类型应该采用两个参数，一个指示事件源的对象源参数
，
封装了有关该事件的任何附加信息的e参数。
的类型e参数应该从EventArgs类派生。对于没有使用任何附加信息的事件
，.NET Framework已经定义了一个适当的委托类型：$ EventBaseBB

a）我认为使用对象源值作为第一个参数有一些好处，因为存在多个对象可以将其事件设置为相同方法的情况。因此，如果我们有10个对象，如果所有10个对象将事件设置为事件处理程序M，那么在M内部，我们可以使用object sender参数值来标识事件调用的启动器。

• 但是据我所知，对象源参数仅在实例方法中引发事件时才有用。因此，如果在静态方法中引发事件，那么对象源参数是没有用的？ b / b> b
  $ b

  b）根据Net Framework指南，是否还有其他利用事件的好处？

  
  
  

  c）无论有什么好处，为什么要减轻麻烦？

  
  
  
  
  
  • 写一个附加代码将所需的参数放入从EventArgs导出的对象中
  
  
  • 在事件处理程序中写入一个附加代码，从EventArgs派生的对象中提取信息？
  
  
  
  
  

  谢谢

  解决方案

  据我所见，有两个主要优点： / p>
  
  

  
  
  • 编写消费该事件的代码的人将会识别该模式，并立即知道如何使用该事件
  
  
  • 事件的签名是以一种对变化的方式制作的。
  
  
  
  
  

  第一点应该很明显，不需要很多细节。

  
  
  

  至于第二点，有t这个原因（在我看来）。首先，由于发件人是对象，事件签名可以被多种类型重用。第二，由于第二个参数是一个 EventArgs decendant，当您介绍自己的 EventArgs 类时，此类可以稍后扩展

  
  
  

  更新
  
  回答问题：

  
  

  我不知道你的意思是是
  能够扩展EventArgs而不用
  更改事件的签名？ >
  

  让我们举个例子，选择以下类：

    public class SomeClass 
   {
   public event EventHandler< FileEventArgs>发生了一些事; 
  } 
   public class FileEventArgs：EventArgs 
   {
   public FileEventArgs（string filename）
   {
   Filename = filename; 
  } 
   public string Filename {get;私人集合} 
  } 
    

  然后我们有一个消费者可以听发生事件事件：

    static void SomethingHappenedHandler（object sender，FileEventArgs e）
   {
   //做某事智能
  } 
    

  现在，让我们说扩展我们传输的信息，其中包含有关文件发生的信息：

    public enum WhatHappened 
   { 
  复制，
  重命名，
  删除
  } 
   public class FileEventArgs：EventArgs 
   {
   public FileEventArgs（string filename，WhatHappened whatHappened）
   {
   Filename = filename; 
   WhatHappened = whatHappened; 
  } 
   public string Filename {get;私人集合} 
   public WhatHappened WhatHappened {get;私人集合} 
  } 
    

  现在，如果我们选择将文件名作为参数发送到事件本身，我们需要通过添加另一个参数来更改事件签名，有效地打破了侦听事件的所有代码。但是由于我们上面的代码只是简单地向 FileEventArgs 类添加了另一个属性，签名保持不变，并且不需要更新任何监听器（除非他们想使用新增的财产，就是）。

  
  

  我写的假设如果事件
  在静态方法中被提出，那么
  对象源参数是
  使用？！

  
  

  是的，这是正确的。我通常通过 null 作为发件人参数从 static 事件（其实这是非常罕见的）。

  
  

  I understand how to use Events according to Net Framework guidelines, but what are the benefits of using this pattern?

  http://msdn.microsoft.com/en-us/library/aa645739%28VS.71%29.aspx :

  The .NET Framework guidelines indicate that the delegate type used for an event should take two parameters, an "object source" parameter indicating the source of the event, and an "e" parameter that encapsulates any additional information about the event. The type of the "e" parameter should derive from the EventArgs class. For events that do not use any additional information, the .NET Framework has already defined an appropriate delegate type: EventHandler.

  a) I see some benefits in using "object source" value as a first parameter since there are situations where multiple objects can have their events set to the same method. Thus, if for example we have 10 objects and if all 10 objects set their events to event handler M, then inside M we can use "object sender" parameter value to identify the initiator of the event call.

  • But as far as I can tell, "object source" parameter is only useful if event was raised inside an instance method. Thus, if event was raised inside static method, then "object source" parameter is of no use?!

  b) Are there other benefits of using events with accordance to Net Framework guidelines?

  c) Whatever the benefits may be, why would they out-weight the trouble of having to

  • write an additional code to put the desired arguments into an object derived from EventArgs
  • write an additional code inside event handlers to extract information from object derived from EventArgs ?

  thank you

  解决方案

  As far as I see it there are two major benefits:

  • People writing code consuming the event will recognize the pattern and immediately know how to use the event
  • The signature of the event is crafted in a way that it is robust towards change

  The first point should be pretty obvious, not needing a lot of elaboration.

  As for the second point, there are two reasons for this (in my opinion). First, since sender is object, the event signature can be reused by several types. Second, since the second parameter is an EventArgs decendant, when you introduce your own EventArgs class this class can be extended later without altering the signature of the event.

  Update
  Response to questions:

  I’m not sure what you mean by " being able to extend EventArgs without altering the signature of the event"?!

  Let's take an example, take the following class:

  public class SomeClass
  {
      public event EventHandler<FileEventArgs> SomethingHappened;
  }
  public class FileEventArgs : EventArgs
  {
      public FileEventArgs(string filename)
      {
          Filename = filename;
      }
      public string Filename { get; private set; }
  }
  

  Then we have a consumer that listens to the SomethingHappened event:

  static void SomethingHappenedHandler(object sender, FileEventArgs e)
  {
      // do something intelligent
  }
  

  Now, lets say that we want to extend the information that we transfer in the event with information about what happened to the file:

  public enum WhatHappened
  {
      Copy,
      Rename,
      Delete
  }
  public class FileEventArgs : EventArgs
  {
      public FileEventArgs(string filename, WhatHappened whatHappened)
      {
          Filename = filename;
          WhatHappened = whatHappened;
      }
      public string Filename { get; private set; }
      public WhatHappened WhatHappened { get; private set; }
  }
  

  Now, if we had chosen to send the filename as a parameter in the event itself, we would need to alter the event signature by adding another parameter, effectively breaking all code that listens to the event. But since we in the code above have simply just added another property to the FileEventArgsclass, the signature remains unchanged, and no listeners need to be updated (unless they want to use the newly added property, that is).

  Am I write in assuming that if event is raised inside static method, then "object source" parameter is of no use?!

  Yes, that is correct. I typically pass null as the sender argument from static events (which, honestly, is very rare).

  这篇关于符合Net指南的事件有什么好处？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！