c# - 事件设计准则[重复项]

This question already has answers here:

Why to not use a custom class instead of inheriting the EventArgs class
                                
                                    （3个答案）
                                
                        
                                3年前关闭。
            
                    
即使设计仅供内部使用的类库，我也会尽量坚持Framework Design Guidelines。

在某种程度上，这使我的生活变得更轻松，因为我使用代码分析来自动检查可能未使用最佳实践的地方。

但是在这种情况下，我感到非常不得不忽略建议。

由于从.NET 4中的EventHandler中删除了EventArgs约束，为什么现在有人要使用从EventArgs派生的类（如https://msdn.microsoft.com/en-us/library/ms229011(v=vs.110).aspx所述），而不是直接使用所需的数据类型并避免分配另一个对象和嵌入所需的数据吗？

例如，必须编写以下内容：

public class ExceptionEventArgs : EventArgs
{
    private readonly Exception _exception;

    public ExceptionEventArgs(Exception exception)
    {
        _exception = exception;
    }

    public Exception Exception
    {
        get
        {
            return _exception;
        }
    }
}

public event EventHandler<ExceptionEventArgs>;

更冗长，因为需要额外分配，而不是：

public event EventHandler<Exception>;

几周前，我什至创建了一个通用的EventArgs以便在另一个类上使用，但这样做只是出于遵守指南的考虑，很愚蠢。

public class EventArgs<T> : EventArgs
{
    private readonly T _data;

    public EventArgs(T data)
    {
        _data = data;
    }

    public T Data
    {
        get
        {
            return _data;
        }
    }
}

所以，使用有什么缺点吗

EventHandler<NotAnEventArgsDerivedClass>

仅用于内部*使用的类？

*我的意思是，要在由多个组件组成的产品上使用-所有这些组件都仅供产品本身使用。

最佳答案

最好不要继承EventArgs。使用没有缺点

EventHandler<NotAnEventArgsDerivedClass>

但是，它仍然假设您想完全通过sender传递object作为sender。

使用EventArgs是唯一可以想到从类继承的地方，因为习惯上，当我们实际上不需要我们要从其继承的类时，通常会使用它。
类似地，我只知道标准Handler(object sender, EventArgs e)委托是基于约定而不是基于该特定方法的要求来设计方法签名的常见情况。它鼓励我们在可能完全不传递传递者的情况下传递无类型参数。它导致我们忽略参数，不信任参数值以及将对象转换为更特定类型的方法，因为我们“只知道”它们的真正含义。

与其他任何设计一样，我们应该创建所需的方法并传递所需的参数。在某些情况下，约定很有用，但这不是其中之一。

关于c# - 事件设计准则[重复项]，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/36509423/