为什么 Combine Publisher 协议的 receive<S> 和 subscribe<S> 具有相同的约束？答案

【问题标题】：Why does the Combine Publisher protocol have receive<S> and subscribe<S> with identical constraints?为什么 Combine Publisher 协议的 receive<S> 和 subscribe<S> 具有相同的约束？
【发布时间】：2020-10-11 02:07:09
【问题描述】：

这是Publisher 协议：

public protocol Publisher {
  associatedtype Output
  associatedtype Failure: Error

  func receive<S>(subscriber: S) 
    where S: Subscriber, Self.Failure == S.Failure, Self.Output == S.Input
}

receive(subscriber:) 函数要求旨在将订阅者附加到发布者。但是，在协议扩展中，有一个非常相似的功能：

extension Publisher {
  public func subscribe<S>(_ subscriber: S) 
    where S: Subscriber, Self.Failure == S.Failure, Self.Output == S.Input
}

receive(subscriber:) 和 subscribe(_:) 对函数有相同的约束。我想知道为什么两者都需要

【问题讨论】：

这可能会有所帮助。 apeth.com/UnderstandingCombine/operators/operatorscustom.html

标签： swift combine

【解决方案1】：

如果您查看反汇编程序中的subscribe 方法，您会发现它可能会执行大量调试/诊断工作。它指的是称为Combine.SubscriberTap 和Combine.DebugHook 的私有类型。

Combine 框架的架构非常“精简”，真的。 receive(subscriber:) 方法在Publisher 和Subscriber 之间创建直接连接。建立此连接后，这些对象可以相互通信，而无需通过任何组合代码调用。（将此与 SwiftUI 架构进行比较，您可以在其中创建 View 对象，但 SwiftUI 会将它们转换为完全不同的对象，例如底层的 UIViews。）

Apple 鼓励您使用subscribe(_:) 方法而不是调用receive(subscriber:)。这使 Combine 框架有机会间接连接您的发布者和订阅者，通过自己的调试钩子路由他们的通信。

【讨论】：