切片职责

做者：Soroush Khanlou，原文连接，原文日期：2016-10-13
译者：Cwift；校对：Crystal Sun；定稿：千叶知风

重构是一个持续性的过程。然而，在频繁的重构过程当中还须要保证开发的功能可用。若是不能保证，代码就不能被按期部署，这会使得你的代码与团队中其余人的代码保持同步变得更加困难。

即使如此，有一些重构难度额外大。在某些特定的状况中，单例的特性会使其与不少不一样的对象耦合，很难从工程中把单例删掉。

许多单例，特别是那些命名不好劲的单例，会逐渐积累无关的行为、数据以及任务，只是由于向单例中增长这些比向其余对象中添加容易不少。

若是想拆分一个影响深远的单例，或者想测试使用单例的代码，就会有不少工做要作。你想用更小、更好的对象慢慢地替换掉单例的引用，可是在彻底完成以前不能删除单例自己，由于还有其余的对象依赖它。

最糟糕的是，不能将单例的行为和方法提取到另外一个对象中，由于它们依赖于单例内部的共享状态。换句话说，若是单例没有任何共享状态，你能够在每次调用时建立一个新的实例，问题就立马解决了。

有一个单例，包含了许多不一样的职责和一堆共享的状态，应用中不少部分都在使用此单例。如何才能在不删除单例代码的状况下解除应用对这个单例的依赖？

须要一种新的方法来引用单例：将单例的海量职责拆分红不一样的片断，这些片断将以单例中的（view）来表示，而不是对单例自己的结构进行实际变动。这个片断的行为和数据能够用协议来表示。

想象一下这种单例在一个虚拟的购物应用中：

class SessionController {

    static let sharedController: SessionController

    var currentUser: User
    
    var cart: Cart
    
    func addItemToCart(item: Item) { }
    
    var fetchedItems: [Item]
    
    var availableItems: [Item]
    
    func fetchAvailableItems() { }
}

这个单例至少有三种职责。咱们想要拆解它，可是代码库中有数十个类引用了这个对象的属性和方法。若是为每一『片』职责定义一个协议，就能够开始拆分它了。

protocol CurrentUserProvider {
    var currentUser: User { get }
}

protocol CurrentCart {
    var cart: Cart { get }
    
    func addItemToCart(item: Item)
}

protocol ItemFetcher {
    var fetchedItems: [Item] { get }
    
    var availableItems: [Item] { get }
    
    func fetchAvailableItems()
}

SessionController 能够遵照下面这些协议，无需任何额外的工做：

class SessionController: CurrentUserProvider, CurrentCart, ItemFetcher {
    //...

得益于 Swift 的协议扩展，咱们能够将任何纯粹依赖于协议的功能转移到协议扩展中。举个例子，availableItems 多是数组 fetchedItems 中 status 属性为 .available 的元素集合。咱们能够把它从单例中移到具体的协议中：

extension ItemFetcher {
    var availableItems: [Item] {
        return fetchedItems.filter({ $0.status == .available })
    }
}

经过这种作法，咱们开始给单例瘦身，提取不相关的细节。

有了这些协议，就能够在应用中使用了。第一步是找到全部用到单例的地方，把单例提取成一个实例变量：

class ItemListViewController {
    let sessionController = SessionController.sharedController
    
    //...
}

接下来能够把它的类型改为具体的协议类型：

class ItemListViewController {
    let itemFetcher: ItemFetcher = SessionController.sharedController
    
    //...
}

如今这个类从技术上来讲仍旧能够访问单例，以受限制的方式访问，很明显这个类只须要使用单例的 ItemFetcher 切片。还没完呢，下一步，使用 ItemFetcher 初始化这个类：

let itemFetcher: ItemFetcher

init(itemFetcher: ItemFetcher) {
    self.itemFetcher = itemFetcher
    super.init(nibName: nil, bundle: nil)
}

如今，这个类不知道初始化时使用的 ItemFetcher 是什么类型的。能够是这个单例，可是也能够是别的类型！这被称为依赖注入。它容许咱们向视图、控制器和其余对象中注入备用的依赖，这将让这些对象的测试变得更加容易。必须更新整个程序中该视图控制器的初始化方式，使用新的构造器。

理想状态下，试图控制器的初始化只在协调器内部完成，因此应减小传入的单例的数量。若是不使用协调器，那么有可能导航控制器中第四个视图控制的任何依赖都须要通过前三个视图控制器的传递。这很不理想。

如今，该处理最困难的部分了：必须在程序中全部引用了单例的地方重复这个操做。这是一个乏味的过程，一旦你弄清楚了各类任务和协议以后，就剩下死记硬背了。（一个提示：若是有一个 CurrentUserProvider，可能须要一个单独的 MutableCurrentUserProvider。只须要从当前用户读取数据的对象也不须要具备写入的权限。）

一旦改变了对单例的全部引用，就拔掉了单例不少的牙齿了。能够删除单例的静态单例访问器属性，而后视图控制器和其余对象将只能使用向它们中传入遵照协议的对象了。

从这里开始，你有几个选择。如今能够轻松地把单例分解成全部轻量级任务。

• 你能够把 ItemFetcher 定义为类而不是协议，而后把全部代码从 SessionController 中转移到新的 ItemFetcher 类中，而后传入类替代单例。

• 你能够将 ItemFetcher 保留为协议，而后建立一个名为 ConcreteItemFetcher 的类，而后把单例中的代码添加到该类中。这个方案给了你更多的选项，能够注入遵照 ItemFetcher 协议的其余对象，适合作单元测试、屏幕截图测试、演示一个应用以及其余用途。工做量会更大，可是同时也更加灵活。

经过在单例上建立职责的“切片”，你能够将单例拆解成任务组件，同时不改变单例自己的结构。可使用依赖注入让对象只能获得但愿它们使用的东西。最后，可使单例再也不具备单例的访问器，而后在优良代码的美好日落中自由骑行。

本文由 SwiftGG 翻译组翻译，已经得到做者翻译受权，最新文章请访问 http://swift.gg。