类为其他类注册事件处理程序是否为不良实践？订阅者需自行注册吗？

这其实不能一概而论——得看具体的场景和你想要实现的设计目标，下面我来拆解你的两个问题：

1. 让其他类为订阅者注册事件处理程序是不良实践吗？ #

绝对不是，很多时候这反而符合好的设计原则。这种模式常见于以下场景：

• 依赖注入（DI）容器：容器会负责在实例化组件时自动关联事件订阅，比如在一些框架中，你可以通过容器配置让某个服务订阅另一个服务的事件。
• 中介者/协调类：就像你示例里的Glue类，它的职责就是组装不同的组件，让发布者和订阅者解耦。发布者只需要专注于发布事件，订阅者只需要专注于处理事件，它们互相不知道对方的存在，完全由Glue来建立关联，这完美契合单一职责原则。
• 模块化系统：当你需要在不同模块之间建立事件关联时，用一个中间类来处理可以避免模块之间产生直接依赖，让系统更易于维护和扩展。

2. 事件订阅者必须自行注册处理程序吗？ #

完全不需要。订阅者自行注册的情况通常是当订阅者需要主动选择关注某个事件时（比如一个用户界面组件主动订阅数据模型的变更事件），但这只是一种场景。

由第三方类来注册的优势很明显：

• 低耦合：发布者和订阅者之间没有直接引用，修改其中一方时不会影响另一方。比如你想替换一个订阅者实现，只需要修改Glue类，不用改动发布者的代码。
• 集中管理：所有的事件关联都在一个地方管理，便于排查问题和调整订阅关系。
• 可测试性：测试发布者时，你可以轻松替换成Mock订阅者；测试订阅者时，也可以用Mock发布者触发事件，不用关心它们的关联逻辑。

结合你的示例分析 #

你的代码示例是一个非常标准的“协调类”用法：

class EventPublisher { public event EventHandler Event; }
class EventSubscriber { public void Handler(object sender, EventArgs e) { } }
class Glue {
    private EventPublisher _publisher = new EventPublisher();
    private EventSubscriber _subscriber = new EventSubscriber();
    public Glue() {
        _publisher.Event += _subscriber.Handler;
    }
}

这里Glue作为协调者，承担了组件组装的职责，让EventPublisher和EventSubscriber保持独立，这种设计是完全合理的，甚至在很多大型系统中是推荐的实践。

需要注意的小细节 #

当然，这种模式也有需要留意的地方：

• 内存泄漏风险：如果第三方类长期持有发布者和订阅者的引用，要确保这些实例在不需要时能被正确回收。比如如果使用DI容器，要注意组件的生命周期配置。
• 职责边界清晰：第三方类（比如Glue）只应该负责组件组装和事件关联，不要让它承担业务逻辑，避免职责混乱。
• 订阅关系的可配置性：如果系统需要动态调整订阅关系，你可以把订阅逻辑从硬编码改成配置驱动，让维护更灵活。

内容的提问来源于stack exchange，提问作者Dave A