注入 Otto 事件总线而不是使用静态单例的优点

Question

在我的 Android 应用中，我使用 Otto 作为事件总线，使用 Dagger 进行依赖注入。

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

通过注入，我必须注入我希望能够在总线上发布 UI 事件的每个自​​定义 View 或 ViewHolder。尤其是使用匕首，在我需要总线的每个类中注入似乎有点笨拙。当然，我可以通过构造函数或 setter 方法传递总线，但如果您考虑使用具有许多不同视图类型的适配器，这也可能有点笨拙。

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

那么，有没有人看到注射 Otto 的任何我看不到的优势？

Answer 1

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

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

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

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

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

相反：考虑一个案例，你去重构你的Views，使得没有任何东西被发布到事件总线（比如，业务需求改变了）。由于Views通知只是通过事件总线松散耦合到包含Fragment或Activity，你很可能会忘记从Fragment和Activity中删除事件处理逻辑，从而留下“死机”代码”后面。这很快就会变得一团糟。

更好的做法是使用观察者设计模式，让Views 直接通知Activities 和Fragments，并且仅在处理涉及另一个组件时（不能从Fragment 和@987654344 轻松到达@; 例如另一个Fragment 或Activity) 将这些组件发布事件到事件总线。如果您遵循这种方法，您将只需要在“顶级组件”中引用事件总线，并且不会涉及任何挣扎。

附：我最近发布了blog post which introduces some best practices for dependency injection in Android。