android - 注入(inject) Otto 事件总线而不是使用静态单例的优势

Question

在我的 Android 应用程序中，我使用 Otto作为事件总线和 Dagger用于依赖注入(inject)。

在 Otto 的用户指南和许多博客文章中，建议使用注入(inject)来获取总线单例。我这样做已经有一段时间了，但最近我越来越怀疑注入(inject)总线是否比使用简单的静态单例有任何优势。

通过注入(inject)，我必须注入(inject)我希望能够在总线上发布 UI 事件的每个自​​定义 View 或 ViewHolder。特别是对于 Dagger ，在我需要总线的地方注入(inject)每个类似乎有点笨拙。当然，我可以通过构造函数或 setter 方法传递总线，但是如果您考虑一个具有许多不同 View 类型的适配器，那也可能有点笨拙。

而且我看不到注入(inject)总线有任何优势。在 Otto 的情况下，注入(inject)了一个具体的实现(Bus 的一个实例)并且永远不会改变。考虑到订阅的工作方式，为解耦包装 Otto 没有任何意义。

那么，有没有人看到注入(inject) Otto 有任何我没有看到的优势？

Answer 1

在我看来，您绝对应该将事件总线包装在您自己的类中，并使用依赖注入(inject)技术将其传递给客户端。

与通过调用静态 getInstance() 方法简单地获取引用相比，这种方法有几个优点:

• 您的依赖关系变得明确。当您通过静态调用获取对对象的引用时，依赖项隐藏在客户端的实现中，这使得代码脆弱且更难理解。
• 如果需要，将更容易切换到不同的事件总线实现。
• 注入(inject)的依赖项更容易在测试中模拟
• 依赖项注入(inject)技术带来一定程度的困难实际上是一件好事 - 如果您遇到困难，这通常表明您做错了什么。对于您的情况，我怀疑您在滥用事件总线。

我说您可能在滥用事件总线，因为我真的不明白为什么您需要在 View 子类中引用它。我猜想您将有关用户交互的通知发布到事件总线，然后将 Activity 或 Fragment 订阅到事件总线以拦截这些事件。在这种情况下，事件总线是一个错误的工具(尽管它工作得很好)。

在这种情况下事件总线是错误工具的原因是因为 Fragments 和 Activity 可以直接访问包含的 View对象。您可以获得对这些 Views 的引用，并将 Fragments 和 Activities 注册为监听器。不需要在这里解耦任何东西。

相反:考虑这样一种情况，您以这样一种方式重构您的Views，不再将任何内容发布到事件总线(例如，业务需求发生变化)。由于 Views 通知仅通过事件总线与包含 Fragment 或 Activity 松散耦合，因此您很可能会忘记删除事件处理来自 Fragment 和 Activity 的逻辑，从而留下“死代码”。这很快就会变得困惑。

更好的做法是使用 Observer 设计模式，让 Views 直接通知 Activities 和 Fragments，并且仅当处理涉及另一个组件时(无法从 Fragment 和 Activity 轻松访问；例如，另一个 Fragment 或 Activity)将这些组件将事件发布到事件总线。如果您采用这种方法，您将只需要在“顶级组件”中引用事件总线，并且不会涉及任何麻烦。

附言我最近发表了一篇 blog post which introduces some best practices for dependency injection in Android .