在软件开发中，API的稳定性和向后兼容性至关重要。然而，随着时间的推移，需求的变化往往会导致API的破坏性变更。本文将探讨如何通过事件处理来减少这种破坏性变更的可能性。
在C#中，事件是一种常见的机制，用于在对象之间传递消息。例如，一个网络连接对象可能会在连接丢失时触发一个事件。但是，如果事件的签名在未来的API版本中发生变化，那么依赖于旧事件签名的代码将无法正常工作。
假设有一个名为Connection的类，它在连接丢失时触发一个名为ConnectionLost的事件。在API的V1版本中，这个事件没有提供任何关于连接丢失原因的信息。现在，希望在API的V2版本中添加这个信息。
在V1版本中，ConnectionLost事件可能以多种方式声明：
public event Action ConnectionLost;
public event Action
在V2版本中，希望添加一个错误代码参数来提供连接丢失的原因。以下是一些可能的事件签名变化：
public event Action ConnectionLost;
public event Action ConnectionLost;
public class ConnectionLostEventArgs {
public int ErrorCode { get; init; }
}
public event EventHandler ConnectionLost;
public struct ConnectionLostEventArgs {
public int ErrorCode { get; init; }
}
public event Action ConnectionLost;
public class ConnectionLostEventArgs {
public int ErrorCode { get; init; }
}
public delegate void ConnectionLostEventHandler(object sender, ConnectionLostEventArgs e);
public event ConnectionLostEventHandler ConnectionLost;
public class ConnectionLostEventArgs {
public int ErrorCode { get; init; }
}
public delegate void ConnectionLostEventHandler(Connection connection, ConnectionLostEventArgs e);
public event ConnectionLostEventHandler ConnectionLost;
如果开发者使用新的API重新编译他们的代码，那么选项1和2肯定会产生破坏性变更。任何参数数量不正确的方法都将无法工作。选项3可能是破坏性变更，如果注册使用了委托类型，那么即使代码重新编译，也会出现问题。选项4到7则不会破坏现有代码，因为事件类型没有变化。
虽然有推荐的实践，但本文展示了多种不同的选项。推荐的实践可能是选项3，这可能会导致破坏性变更。尽管在某些情况下它可能不会（用户只使用了+=和-=方法，从未编写过EventHandler类型，并且重新编译了代码），但作为破坏性变更的规则，使用选项3是不利的。
目前没有完美的解决方案。创建一个事件参数然后使用EventHandler