我一遍又一遍地发现自己按照指南在C#中实现事件,然后当客户端代码不需要指南添加的任何好处时,再使用Action回到更简单的实现。
可以说,我会添加省略发件人对象,除非实际需要是一件好事,因为它促进了触发器和处理程序的分离。更一般地说,我认为避免编写不需要的代码是一个好习惯。
我并不是说应该始终驳回指南, 有以下好处(参见下面的链接)。我的问题是,我是否始终遵循它。
以下示例显示了如何将“天真事件”模式与指南模式进行比较。
// This is neat
class NaiveEvents
{
public event Action<string> OnAlert;
public void TriggerOnAlert(string message)
{
OnAlert(message);
}
}
// Is this bloated?
class ProperEvents
{
public event EventHandler<OnAlertEventArgs> OnAlertEvent;
public void TriggerOnAlert(string message)
{
OnAlertEvent(this, new OnAlertEventArgs(message));
}
public class OnAlertEventArgs : EventArgs
{
private readonly string _message;
public OnAlertEventArgs(string message)
{
_message = message;
}
public string Message { get { return _message; } }
}
}
class EventsDemo
{
public static void DemoNaiveEvents()
{
var ev = new NaiveEvents();
ev.OnAlert += (msg) => { Console.WriteLine(msg); };
ev.TriggerOnAlert("Hello World");
}
public static void DemoProperEvents()
{
var ev = new ProperEvents();
ev.OnAlertEvent += (sender, args) => Console.WriteLine(args.Message);
ev.TriggerOnAlert("Hello World");
}
}
请参阅指南:http://msdn.microsoft.com/en-us/library/w369ty8x.aspx
好处:What are the benefits of having events conforming to Net guidelines?
谢谢!
答案 0 :(得分:4)
指南或惯例是任意的,不适用于所有情况,环境,解决方案或观点,但这就是创建这些文档的原因:标准化。
有时某些指南似乎毫无用处,但我的观点从不遵循指南和/或约定会比不这样做更糟糕。
可维护性,代码重用,可预测性,可读性以及每天缺乏讨论,因为对于我来说,每个开发人员对琐事都有他/她的看法,比任何事情都更有价值。
关注您当前的问题,并根据我上面所说的,即使没有性能或设计质量的好处,我建议并建议,如果某些软件开发用于专业目的,则必须遵循全局指南和惯例。如果是开源音频,那么也应该遵循这些。
作为一名爱好者和专业开发人员,我喜欢编写,阅读和维护遵循事实上的编码标准的代码,因为我知道每个人都会理解我的工作 - 显然,文档是有利的! -
答案 1 :(得分:1)
我的设计(以及类似的情况)通常是应用程序和库代码的不同。
对于可重用的库,我倾向于更多地遵循guidlines,因为这样可以提供更好的版本控制语义。改变图书馆的公共API非常烦人。
在应用程序代码中,我试图妥协更多。重构仅在单个解决方案中使用的这种事件处理程序并不是那么多工作。所以使用你的简化模式就是OK IMO。
答案 2 :(得分:1)
从我的观点来看,遵循这种模式的最大好处是你可以拥有可互换的事件处理程序。例如,如果您已定义
public void OnClick(object sender, EventArgs e)
在某处处理点击事件的方法,如果需要将其连接到OnAlert事件,而不必包装签名,这将是微不足道的。然而,这在C#&gt;中是微不足道的。 3.0使用lambdas所以增益可以很小。回到匿名代表的前一天,这样做更难以遵循指南