可以使用哪种设计模式来代替 Manager 类？答案

【问题标题】：Which design pattern can be used instead of Manager class?可以使用哪种设计模式来代替 Manager 类？
【发布时间】：2020-02-29 19:39:35
【问题描述】：

我有一个名为PhotoManager 的类，它是一个单例。此类包含以下方法：

fun downloadPhoto(context: Context, photoUrl: String) { }

fun savePhotoUri(context: Context, uri: Uri) { } 

fun setWallpaper(context: Context, photoUri: Uri) { }

我还有一些其他类的名称中有Manager 后缀。例如，SuggestionManager 接收一些输入数据并返回基于用户的建议。

我想重构这两个类，但我不知道使用哪种模式。可以是Facade模式吗？

【问题讨论】：

标签： android kotlin design-patterns

【解决方案1】：

PhotoManager 为什么存在？ PhotoManager 有任何状态吗？如果没有，那就摆脱它。在 Kotlin 中，您可以拥有类之外的函数。

如果它确实有状态，那么找出你为什么需要这个类，这将帮助你找出更好的名字。

“PhotoManager”是个坏名字，因为没有人认为“我需要一些东西来管理我的照片”......如果有人确实这么认为，那么你的班级听起来它不会完成这项工作。作为您班级的消费者，我有什么意义？

【讨论】：

PhotoManager 没有任何状态。它只包含了诸如downloadPhoto、setWallpaper之类的util函数，所有这些函数都是独立的。例如，我不能使用 ViewModel，因为我在多个地方需要这些功能，并且多个 ViewModel 正在使用这个类。
那就别上课了。在名为 Photos.kt 或类似文件的文件中创建像 downloadPhoto 这样的顶级函数。从签名看，你可能想让它们扩展为Context，所以你可以写theContext.downloadPhoto(theUri)，例如

【解决方案2】：

如果您想将您的类称为管理器并经常使用单例，在大多数情况下，这意味着您对设计模式及其解决的问题缺乏了解。

类似的问题已经被问过很多次了，我只是觉得在这个阶段，你可以从下面的一些话题中得到启发。

Naming Classes - How to avoid calling everything a "<WhatEver>Manager"?

How to avoid …Helper or …Manager classes

The Clean Code Talks - "Global State and Singletons"

【讨论】：

【解决方案3】：

在处理来自远程源的图像时，我建议遵循存储库模式。它会给你更多的灵活性，并且更容易扩展和维护。对于 Android，Google 在Guide to app architecture 中描述了该模式。有很多技术可供选择，所以在开始编码之前做一些研究。

这应该涵盖前两种方法。至于其他人，我认为我不了解他们的哪些工作做得足够好，无法提出解决方案。

【讨论】：