拥有代理经理是一个好的设计理念吗？

Question

许多 Android 应用都包含自己的 BaseActivity 类，应用中的所有 Activity 都扩展了该类。这很有用，因为它为放置大多数/所有活动共有的功能提供了一个中心位置。拥有 BaseActivity 的主要缺点是您无法使用任何 Activity 子类（ListActivity 等）。

另一种方法是使用 ActivityDelegate。这为功能提供了一个中心位置，同时仍然允许您使用 Activity 子类。它也可以说更具可测试性，因为它使用组合而不是继承。

当 BaseActivity/ActivityDelegate 变得太大且过于复杂时，这两种解决方案都可能导致大量意大利面条式代码。一个可能的解决方案是使用委托模式，但将功能拆分为许多不同的委托。这减少了 Delegates 中的意大利面条式代码，但随后 Activity 变得更加复杂 - 他们现在正尝试将其 on* 方法转发给许多不同的 Delegates 而不仅仅是一个。

所有这些问题的可能解决方案是使用代理管理器。代表管理器跟踪应用程序中所有较小的代表。活动将它们的 on* 方法转发给委托管理器，委托管理器将它们转发给所有单独的委托。这完成了以下所有工作：

• 重复数据删除代码 - 所有常用功能都放入其中一个委托中
• 允许使用 Activity 子类
• 所有活动中的简单代码 - 所有 on* 方法都只转发给一个类
• 易于测试 - 可以轻松模拟 Delegates 和 Delegate Manager 周围的所有内容以进行单元测试

有没有人尝试过使用这种模式？如果有，进展如何？

Answer 1

据我了解，您说的是整个应用程序的一个 DelegateManager 对象。如果是这种情况，可以使用registerActivityLifecycleCallbacks，见http://developer.android.com/reference/android/app/Application.html#registerActivityLifecycleCallbacks%28android.app.Application.ActivityLifecycleCallbacks%29

如果您使用的是 https://github.com/BoD/android-activitylifecyclecallbacks-compat。

registerActivityLifecycleCallbacks 让您可以连接到活动 onXXX 生命周期方法。

这样做肯定有您描述的所有好处：

• 仅当您实际需要重复行为时才可用解耦，这对于以 Activity 的工作方式捆绑在一起的控制器+视图逻辑来说很少见。
• 如果您有可能重用的活动，删除继承是很好的 - 但我以前从未这样做过。但我想一个很好的用例是您自己处理设置的活动或需要应用程序范围的 L&F 和行为的类似活动。

在我的脑海中，我能想到这些缺点：

• 在各处使用侦听器会模糊应用程序活动/调用层次结构的路径，并使代码难以理解。这适用于所有侦听器/调度程序类型的编程。这是一个强大的工具，但要小心使用。
• 如果您所做的只是传递给生命周期侦听器/委托，它可能会引入很多（正如您提到的）样板/意大利面条代码。
• 您有责任通过Application.unregisterActivityLifecycleCallbacks 从应用程序中注销您自己。我不认为有什么好办法，

就我个人而言，我并没有在生命周期中大量使用这种设计模式，但对于某些用例来说可能是值得的。例如：

• ApplicationLifecycleLogger：每次您创建/恢复/暂停...一个活动时，您都会记录一下日志或其他东西，从而使调试生命周期变得更容易一些。
• 例如，如果某人由于某种模型状态（例如响铃警报-> 无法进入AlarmEditActivity）而进入他/她不允许进入的活动，您可以在此处执行finish()。
• 在没有 Parcelable:s 和屏幕旋转更改的情况下跨活动边界传递对象状态。通常这是通过应用程序中的地图或某处的某个静态字段来实现的。您可以通过让委托人保持状态来做到这一点。

另外，看看：Is there a design pattern to cut down on code duplication when subclassing Activities in Android?

我希望这会有所帮助 =)