事件真的会使代码分离吗？
所以我试图使用事件来解耦我所拥有的代码，这是我的问题：
class WorldHandler { public void Notify(object sender, EventArgs e) { if (e is CameraMovedEventArgs) { // handle event } if (e is MapLoaded) { // handle event } } } WorldHandler类侦听我的应用程序的不同子系统。 这是不是意味着WorldHandler仍与其他子系统结合？ 直接访问这个类中的子系统不是一样的吗？
如果我很难理解我的要求，我会在post中添加其他信息。
我对这个问题进行了研究，但我仍然觉得这很令人困惑，因为不同的人对如何将代码与事件分离有不同的看法。
是的，您的代码仍然是耦合的，您不仅可以直接引用该类（当您连接事件处理程序时），而且您还可以引用包含正在监视的类的程序集。
您可以通过使用监视类上的接口并仅通过接口上公开的项访问它来最小化耦合。 理想情况下，此接口应位于观察者和观察者参考的第三个“更常见”的组件中。 您还可以通过使用Prism中的EventAggregator之类的东西来最小化或消除事件耦合。
耦合本身并不坏，它简单地使得更换实现并替换它们变得更加困难（或者更昂贵） – 如果没有适当的解耦，则会有更多的工作和更多的错误风险。 您的应用程序可能不需要正确的解耦 – 这取决于您打算如何处理它。
使用事件来对发生的事情做出反应就是脱钩。 与事件脱钩也不错，我建议你这样做。 事件的目的是某些类说“我已经完成了这个”或“我即将这样做”，如果需要，其他类可以对事件作出反应。 发送事件的类通常不知道是否有任何其他类对它做出反应，除非你当然告诉它。
一般来说，事件可以帮助您解耦代码，因为对于事件源，所有事件订阅者都是匿名的。 换句话说，事件源不需要知道事件接收器。 订阅事件的人（它不一定是接收器）与源相关联。
这不仅适用于.NET事件的特殊情况，也适用于观察者模式等机制，后者在Java世界中广泛用于与.NET事件相同的目的。
顺便说一句：如果方法不会为所有事件调用相同的操作，那么让一个方法订阅多个事件通常不是一个好主意。 更好的方法是使用单独的处理程序方法，例如：
public void NotifyCameraMoved(object sender, EventArgs e) { // handle event } public void NotifyMapLoaded(object sender, EventArgs e) { // handle event }
解耦不会删除程序的所有组件之间的所有依赖关系，您不应该将Decoupling / Coupling与Cohesion混合使用，当它具有松耦合时（软件总是存在），软件就很好。
尽管如此，事件仍然有助于代码解耦，触发事件的源，以及它的订阅者是完全不同的和独立的对象