Android 架构 UseCase最佳实践
- 前言
- UseCase 的职责
- UseCase 的命名
- UseCase 的线程安全
- UseCase 的签名依赖
- UseCase 的引用透明
- UseCase 的接口抽象
前言
Android 官方的最新架构中引入了 Domain （网域层 or 领域层），Domain Layer 由一个个 UseCase 组成。但是由于团队套用官方新架构后没有正确地定义 UseCase，无法发挥 Domain Layer 应有的架构价值。
本文就带大家一起梳理 UseCase 常见的使用误区和最佳实践。
UseCase 的职责
一句话概括，UseCase 用来封装可复用的单一业务逻辑。这里的两个关键词一个是单一、一个是业务逻辑。
首先 UseCase 应该用来定义一段 Logic，这段 Logic 与 UI 以及 Data 的访问方式无关，是独立于 UI 和 Data 之外的 Business。
我们都知道良好的架构应该做到关注点分离，即表现层和数据层的解耦。领域层一定程度扮演着这个解耦的角色，但是如果仅仅是为了做隔离和解耦，只要定义好 ViewModel 即可，没必要引入 Domain 和 UseCase 这一新的层级概念，所以官方文档也说了 Domina 层是可选的。
UseCase 如果存在，则其逻辑应该有一定的复杂度，这样才有被“封装”的价值。举一个例子，一个支付相关的业务逻辑，应该包含事务的发起和结束以及，以及事务过程中的异常处理：
class SendPayment(private val repo: PaymentRepo) {
suspend operator fun invoke(
amount: Double,
checkId: String,
): Boolean {
val transactionId = repo.startTransaction(params.checkId)
repo.sendPayment(
amount = params.amount,
checkId = params.checkId,
transactionId = transactionId
)
return repo.finalizeTransaction(transactionId)
}
}
此外，一个 UseCase 应该是单一职责，甚至可以就是一个 Functioin，这样才能以更小颗粒度被复用，提升复用范围也更易于测试。一个检验 UseCase 是否职责单一的方法是看它的命名是否语义明确，好的命名应该是一个具体动作。
一个名词命名的 UseCase 很难做到职责单一，如 GalleryUseCase，这类对象往往基于 OOP 思想设计，内部多个成员方法。经验告诉我们，方法越多，单一方法的价值越低，有的多方法的 UseCase 没提供什么业务价值，甚至沦为了一个 Repository 的 Wrapper。
好的 UseCase 只要完成一件有价值的业务即可，Repository 只是它完成业务工具。价值体现在业务逻辑具备一定的复杂度，何为“复杂”，前面已经举例了。
下面是 UseCase 是否职责单一的正反例子
// DON'T ❌ - 名词命名，
// 一般是OOP思想下的产物，功能多，容易违背单一职责
class GalleryUseCase @Inject constructor(
/*...*/
) {
fun saveImage(file: File)
fun downloadFileWithSave(/*...*/)
fun downloadImage(/*...*/): Image
fun getChatImageUrl(messageID: String)
}
// DON'T ❌ - 只是一个 Repository 的包装器
class GetSomethingUseCase @Inject constructor(
private val repository: ChannelsRepository,
) {
suspend operator fun invoke(): List<String> = repository.getSomething()
}
// DO ✅ - 动词命名，单一职责
class SaveImageUseCase @Inject constructor(
/*...*/
) {
operator fun invoke(file: File): Single<Boolean>
// 这里虽然有多个方法，但其实是重载方法，职责上仍然是单一的
operator fun invoke(path: String): Single<Boolean>
}
class GetChatImageUrlByMessageIdUseCase() {
operator fun invoke(messageID: String): Url {...}
}
单一职责下的 UseCase 可以更好地被其他 UseCase 使用，官方文档也鼓励通过 UseCase 的组合调用实现更复杂的业务逻辑。
UseCase 的命名
前面提过，UseCase 的命名通常是一个语义明确的动作：动词（一般现在时） + 名词（） + UseCase
例如 FormatDateUseCase, GetChatUserProfileUseCase, RemoveDetektRulesUseCase 等。UseCase 类中的函数可以直接使用 invoke 操作符重载，也可以给一个动词作为名字
class SendPaymentUseCase(private val repo: PaymentRepo) {
// using operator function
suspend operator fun invoke(): Boolean {}
// normal names
suspend fun send(): Boolean {}
}
// --------------Usage--------------------
class HomeViewModel(): ... {
fun startPayment(...) {
sendPaymentUseCase() // using invoke
sendPaymentUseCase.send() using normal functions
}
}
invoke 操作符更优于常规函数，因为：
- 开发者只要给 UseCase 一个合适的命名即可，无需考虑函数的命名
- 调用起来非常简单
- 便于重载，当增加新的非 invoke 方法时也比较容易被察觉，避免单一职责的劣化
UseCase 的线程安全
官方文档提到 UseCase 应该是 Main-safe 的，即可以在主线程安全的调用，其中的耗时处理应该自动切换到后台线程。
// DON'T ❌ - add 和 sort 都是耗时操作，不能直接在主线程执行
class AUseCase @Inject constructor() {
suspend operator fun invoke(): List<String> {
val list = mutableListOf<String>()
repeat(1000) {
list.add("Something $it")
}
return list.sorted()
}
}
// DO ✅ - 主线程调用下，也不用担心性能问题
class AUseCase @Inject constructor(
// or default dispatcher
@IoDispatcher private val dispatcher: CoroutineDispatcher,
) {
suspend operator fun invoke(): List<String> = withContext(dispatcher) {
val list = mutableListOf<String>()
repeat(1000) {
list.add("Something $it")
}
list.sorted()
}
}
// DON'T ❌ - 避免过度切换线程
// Repository 应该也是 main safe 的，所以没必要再切换一次 Context， 直接调用节课
class AUseCase @Inject constructor(
private val repository: ChannelsRepository,
// or default dispatcher
@IoDispatcher private val dispatcher: CoroutineDispatcher,
) {
suspend operator fun invoke(): List<String> = withContext(dispatcher) {
repository.getSomething()
}
}
UseCase 的签名依赖
UseCase 应该是一段纯业务逻辑，它的函数签名（输入输出）不应该依赖 UI 或平台设备相关的依赖，包括 Context 类，这样才具备更好的可复用性。
此外，UseCase 的签名不应该以来 UI层的 Model，这会让 UseCase 沦为从 Data Model 到 UI Model 映射的工具，这是 ViewModel 的事情。
对于异常，UseCase 只需要返回 error code 类型而不是具体的 message，error messag 应该由 UI 基于 error code 生成。
// DON'T ❌ - 不应该依赖任何 Android 平台相关对象，甚至 Context
class AddToContactsUseCase @Inject constructor(
@ApplicationContext private val context: Context,
) {
operator fun invoke(
name: String?,
phoneNumber: String?,
) {
context.addToContacts(
name = name,
phoneNumber = phoneNumber,
)
}
UseCase 的引用透明
如果将 UseCase 认为是一个函数，那么它最好具备一个纯函数的特性，内部不应该包含 mutable 的数据。
UseCase 本身不持有可监听的状态，它内部如果隐藏了可变数据，且在业务逻辑会受到内部可变数据的影响，会破坏 UseCase 的幂等性，在多场景复用时会出现相同输入但输出不同的情况。
// DON't ❌
class PerformeSomethingUseCase @Inject constructor() {
val list = mutableListOf<String>()
suspend operator fun invoke(): List<String> {
repeat(1000) {
list.add("Something $it")
}
return list.sorted()
}
}
好的 UseCase 其唯一输入只会得到唯一输出，这被称为引用透明。
UseCase 的接口抽象
有一些文章会看到对 UseCase 做接口抽象和派生。
//定义 UseCase 接口
interface GetSomethingUseCase {
suspend operator fun invoke(): List<String>
}
//UseCase 派生类
class GetSomethingUseCaseImpl(
private val repository: ChannelsRepository,
) : GetSomethingUseCase {
override suspend operator fun invoke(): List<String> = repository.getSomething()
}
如上，定义 UseCase 的接口和对应实现，然后在 DI 容器中，可以通过 @Bind 提供实例注入。其实这种属于过度设计，单一职责的 UseCase 应该只有一个方法或一类重载方法，而且方法最好是纯函数逻辑，不依赖 UseCase 对象的任何状态，因此从这个角度讲，UseCase 可以是一个单例，直接使用 object 定义。
有时候 UseCase 需要动态依赖不同的 Repository，此时可以使用 class 定义 UseCase，按需实例化使用，或者在 DI 容器中被动注入，此时依赖的 Repository 可以从 DI 容器中自动获取。在 class 之外再定义一个 interface 必要性不大。
当然，还有一种使用 Kotlin 的 function interface 来定义 UseCase 的技巧，这里的 interface 主要目的不是为了抽象，而是想利用其单方法接口的特性，约束 UseCase class 里定义太多方法。
比如 , 像下面这样定义一个 UseCase 的单方法接口：
fun interface GetSomethingUseCase : suspend () -> List<String>
此时需要像下面这样实例化，只能定义一个方法，强制确保单一职责
val getSomethingUseCase = GetSomethingUseCase {
repository.getSomething()
}
