我可能只是神经质,但我经常发现自己在发布事件的类中,我觉得很方便地从类本身(例如在构造函数中)订阅这个事件,而不仅仅是从外部类订阅.
这对我来说听起来很合理,但是我忍不住尴尬地说,这是一个糟糕的做法,原因很简单,我总是面对这样一个问题：“为什么不执行你在事件处理程序中提供的动作在代码中触发事件？“
public class Button
{
public Button()
{
this.Click += someHandler; // bad practice?
}
public event EventHandler Click;
public void HandleInput()
{
if (someInputCondition)
{
// Perform necessary actions here rather than
// subscribing in the constructor?
this.Click(this,...);
}
}
}
订阅自己的活动有任何缺点吗？
解决方法
This sounds reasonable to me,but I can’t help the nagging feeling that it’s a poor practice,for the simple reason that I’m always faced with the question: “Why not perform the actions that you’d provide in the event handler in the code which fires the event?”
要回答这个问题,请考虑部分类场景.假设你有一个基本类型B.你运行一个自动化的工具,通过将B扩展到派生类D来装饰B.你的工具生成一个部分类,以便消费D的开发人员可以进一步自定义它.
在这种情况下,D的用户创作方希望在由D声明的事件或D的机器生成侧由D的机器生成侧提升时,D的用户创作方将要注册.
这就是我们在多年前设计VSTO时所发现的情景.事实证明,在C#中做到这一点并不困难,但是在VB中完成所有操作是相当棘手的.我相信VB已经对他们的活动订阅模式进行了一些调整,使得这更容易.
说：如果你能避免这个,我会的.如果您只是在内部订阅活动,似乎是一个坏的代码气味. C#3中的部分方法在这里有很大的帮助,因为它们使得机器生成端在用户生成的一方调用很少的通知功能变得简单而且成本低廉,而无需发布事件的麻烦.
