Swift高级分享 - 在Swift中提取视图控制器操作

视图控制器往往在为Apple平台构建的大多数应用程序中起着非常重要的作用。他们管理我们UI的关键方面，提供系统功能的桥梁，如设备方向和状态栏外观，并经常响应用户交互 - 如按钮点击和文本输入。

由于它们通常具有这样的关键作用，因此许多视图控制器最终遭受常见的大规模视图控制器问题并不奇怪- 当它们最终承担太多责任时，导致大量交织在一起的逻辑，通常与视图混合在一起和布局代码。

虽然我们已经探索了多种减轻和分解大视图控制器的方法 - 例如使用合成，将导航代码移动到专用类型，重用数据源和使用逻辑控制器 - 本周，我们来看一下技术这让我们可以提取视图控制器的核心操作，而无需引入任何其他抽象或架构概念。

尴尬的意识

许多类型的架构和结构问题的一个非常常见的根本原因是某些类型只是意识到太多的域和细节。当给定类型的“意识领域”增长时，通常会履行其职责，并且 - 作为直接影响 - 它包含的代码量。

假设我们正在为消息传递应用程序构建一个作曲家视图，为了能够从用户的联系人中添加收件人并启用消息发送，我们目前允许我们的视图控制器直接访问我们的数据库和网络代码：

class MessageComposerViewController: UIViewController {
    private var message: Message
    private let userDatabase: UserDatabase
    private let networking: Networking

    init(recipients: [Recipient],
         userDatabase: UserDatabase,
         networking: Networking) {
        self.message = Message(recipients: recipients)
        self.userDatabase = userDatabase
        self.networking = networking
        super.init(nibName: nil, bundle: nil)
    }
}

上面可能看起来不是什么大问题 - 我们使用依赖注入，并不像我们的视图控制器有大量依赖。然而，当我们的视图控制器还没有变成一个巨大的一个，只是还没有，它确实有它需要处理的动作相当多的数量-如添加收件人，取消和发送邮件-它目前正在对所有的它自己的：

private extension MessageComposerViewController {
    func handleAddRecipientButtonTap() {
        let picker = RecipientPicker(database: userDatabase)

        picker.present(in: self) { [weak self] recipient in
            self?.message.recipients.append(recipient)
            self?.renderRecipientsView()
        }
    }

    func handleCancelButtonTap() {
        if message.text.isEmpty {
            dismiss(animated: true)
        } else {
            dismissAfterAskingForConfirmation()
        }
    }

    func handleSendButtonTap() {
        let sender = MessageSender(networking: networking)

        sender.send(message) { [weak self] error in
            if let error = error {
                self?.display(error)
            } else {
                self?.dismiss(animated: true)
            }
        }
    }
}

让视图控制器执行自己的操作可能非常方便，对于更简单的视图控制器，它很可能不会导致任何问题 - 但正如我们只看到上面的摘录所看到的那样MessageComposerViewController，它通常需要我们的视图控制器知道他们理想情况下不应过于关注的事情 - 例如网络，创建逻辑对象，以及对父母如何呈现它们做出假设。

由于大多数视图控制器已经非常忙于创建和管理视图，设置布局约束以及检测用户交互等内容 - 让我们看看我们是否可以提取上述操作，并使我们的视图控制器更简单（并且不太清楚）处理。

操作

动作通常有两种不同的变体 - 同步和异步。某些操作只需要我们快速处理或转换给定值，并直接返回，而其他操作则需要更多时间来执行。

为了对这两种动作进行建模，让我们创建一个通用Action枚举 - 实际上并没有任何情况 - 但是包含两个类型别名，一个用于同步动作，一个用于异步动作：

enum Action<I, O> {
    typealias Sync = (UIViewController, I) -> O
    typealias Async = (UIViewController, I, @escaping (O) -> Void) -> Void
}

我们使用的原因，enum我们的Action包装上面，以防止它被实例化的类型，而不是只充当一个“抽象的命名空间”。

使用上面的类型别名，我们现在可以定义一个元组，其中包含我们MessageComposerViewController可以执行的所有操作- 如下所示：

private extension MessageComposerViewController {
    func handleAddRecipientButtonTap() {
        actions.addRecipient(self, message) { [weak self] newMessage in
            self?.message = newMessage
            self?.renderRecipientsView()
        }
    }

    func handleCancelButtonTap() {
        actions.cancel(self, message)
    }

    func handleSendButtonTap() {
        let loadingVC = add(LoadingViewController())

        actions.finish(self, message) { [weak self] error in
            loadingVC.remove()
            error.map { self?.display($0) }
        }
    }
}

值得注意的是，作为此重构的一部分，我们还改进了收件人添加到邮件的方式。我们不是让视图控制器本身执行其模型的变异，而是简单地返回一个新Message值作为其addRecipient动作的结果。

上述方法的优点在于我们的视图控制器现在可以专注于视图控制器最擅长的 - 控制视图 - 并让创建它的上下文处理网络和呈现等细节RecipientPicker。以下是我们现在可以在另一个视图控制器上呈现消息编写器的方法，例如在协调器或导航器中：

func presentMessageComposerViewController(
    for recipients: [Recipient],
    in presentingViewController: UIViewController
) {
    let composer = MessageComposerViewController(
        recipients: recipients,
        actions: (
            addRecipient: { [userDatabase] vc, message, handler in
                let picker = RecipientPicker(database: userDatabase)

                picker.present(in: vc) { recipient in
                    var message = message
                    message.recipients.append(recipient)
                    handler(message)
                }
            },
            cancel: { vc, message in
                if message.text.isEmpty {
                    vc.dismiss(animated: true)
                } else {
                    vc.dismissAfterAskingForConfirmation()
                }
            },
            finish: { [networking] vc, message, handler in
                let sender = MessageSender(networking: networking)

                sender.send(message) { error in
                    handler(error)

                    if error == nil {
                        vc.dismiss(animated: true)
                    }
                }
            }
        )
    )

    presentingViewController.present(composer, animated: true)
}

太可爱了！由于我们所有的视图控制器的操作现在都只是函数，因此我们的代码变得更加灵活，更容易测试 - 因为我们可以轻松地模拟行为并验证在各种情况下调用正确的操作。

可操作的概述

从私有方法和专用集合中提取操作的另一大好处是，可以更容易地了解给定视图控制器执行的操作类型 - 例如ProductViewController，这具有四个同步的非常清晰的列表和异步操作：

extension ProductViewController {
    typealias Actions = (
        load: Action<Product.ID, Result<Product, Error>>.Async,
        purchase: Action<Product.ID, Error?>.Async,
        favorite: Action<Product.ID, Void>.Sync,
        share: Action<Product, Void>.Sync
    )
}

添加对新操作的支持通常也变得非常简单，因为我们不必为每个视图控制器注入新的依赖项并编写特定的实现，我们可以更轻松地利用共享逻辑并简单地向我们的Actions元组添加新成员- 然后在调用时调用它发生了相应的用户交互。

最后，操作可以实现类型自定义和更简单的重构等功能，而无需通常需要的“仪式”来解锁此类功能 - 例如，在使用协议时，或切换到新的，更严格的架构设计模式时。

例如，假设我们想要MessageComposerViewController从之前返回到我们，并添加对保存未完成消息草稿的支持。我们现在可以实现整个功能，甚至无需触及我们的实际视图控制器代码 - 我们所要做的就是更新其cancel操作：

let composer = MessageComposerViewController(
    recipients: recipients,
    actions: (
        ...
        cancel: { [draftManager] vc, message in
            if message.text.isEmpty {
                vc.dismiss(animated: true)
            } else {
                vc.presentConfirmation(forReason: .saveDraft) { 
                    outcome in
                    switch outcome {
                    case .accepted:
                        draftManager.saveDraft(message)
                        vc.dismiss(animated: true)
                    case .rejected:
                        vc.dismiss(animated: true)
                    case .cancelled:
                        break
                    }
                }
            }
        },
        ...
    )
)