我正在开发一个由 3 个主要部分组成的 Android 测试项目，每个部分都是按照 MVP 模式 开发的。
这些部分是 嵌套的 彼此，我想知道我遵循的策略是否正确/最好
结构:
每个部分都使用一个MVP结构(例如，对于Book我制作了BookPresenter、BookView和BookModel，对于Page和Item也是如此)
作为 用户案例 我想跟踪用户点击按钮的次数，每次将页面背景更改为随机颜色，当用户点击第 10 次时告诉 BookPresenter 转到第二个页。
为此，我进行了设置
在所有这些中，BookPresenter 有一个对 PagePresenter 的引用，而 PagePresenter 有一个对 ItemPresenter 的引用，因此当需要发生某些操作时，它们可以与结构中的子级或父级 Presenter 进行通信
现在问题是:
这是使用嵌套 MVP 设置系统的正确方法吗？
因为如果我然后想要一个 PageView 而不是在 Book 中，我需要将它放在 Newspaper 中(其他类具有一些替代 Book 的行为)，我仍然需要使用 Presenters 和所有其他部分重新创建整个依赖链...
最佳答案
“Child-Presenter”如何与其“Parent-Presenter”沟通？他们不(直接，不通过 EventBus)
从我的角度来看，这种父子关系是代码异味，因为它们在父子之间引入了直接耦合，这导致代码难以阅读、难以维护，不断变化的需求会影响很多组件(因此它是在大型系统中几乎不可能完成的任务)，最后但并非最不重要的是引入了难以预测甚至更难以重现和调试的共享状态。
到目前为止一切顺利，但不知何故，信息必须从演示者 A 流向演示者 B:演示者如何与另一个演示者通信？他们没有!演示者必须告诉另一个演示者什么？事件X发生了？演示者不必相互交谈，他们只是观察相同的模型(或者准确地说是业务逻辑的相同部分)。这就是他们从底层获得更改通知的方式。
每当事件 X 发生(即用户单击 View 1 中的按钮)时，Presenter 就会让该信息下沉到业务逻辑中。由于其他 Presenter 正在观察相同的业务逻辑，因此业务逻辑会通知他们某事已更改(模型已更新)。
资料来源:http://hannesdorfmann.com/android/mosby3-mvi-4
因此，让我们将其应用于您的示例。
你应该有类似 Readable 的东西(如果你想对 Book implements Readable 和 NewsPaper implements Readable 进行抽象)。使用 Readable.getPageCount() 您可以获得 ViewPager 的页数。使用 Readable.getCurrentPage() 可以获得当前的 Page 。然后，您需要某种观察者模式，以便在页面更改时收到通知。当用户单击 ItemView 中的按钮时，您还需要一个 Listener/Observer 模式。此类点击将是上图中的事件 X。单击按钮时，您可以让信息通过 Presenter 向下流到更改 Readable 对象的业务逻辑。然后，此更改将通知观察者此 Readable 对象(如 PagePresenter)，然后更新 PageView 以设置页面的背景颜色。
所以关键是:通过业务逻辑进行通信，而不是一些 View to View 或 Presenter to Presenter 通信。
希望有帮助。