ios - 为什么不通过 2 个 segue 在 View 之间发送消息，而是通过 segue 和删除

Question

我对这种设计模式很困惑，而且我相信我目前没有掌握所有要点。

让我们在这里放一个简单的场景:

两个 View ，比如 A 和 B，数据通过一个 segue 从 A 传递到 B。但是当 B 想要将数据传递回 A 或更改/更新一些属于 A 的数据源的数据时，这里使用委托(delegate)!。 为什么不做 2 个 segue 并让它们传递数据？

我的理解是:

Segue 是一个“硬”连接， Controller A 通过一个 segue 建立到 Controller B 的连接意味着它必须知道 Controller B，因此，A 保留对 B 的引用。另一方面，委托(delegate)是一个“丢失” "从 B 到 A 的连接，所以 B 对 A 了解不多。因此 A 到 B 是“硬”连接，B 到 A 是“丢失”连接，这可以避免内存泄漏问题。

问题1:我的理解有没有错误？

问题 2:使用转场和委托(delegate)模式还有其他原因吗？

问题 3:如果委托(delegate)这么好，为什么不使用 2 个委托(delegate)来进行所有数据传递和消息传递？

非常感谢您的时间和帮助

Answer 1

Is any there errors in my understanding?

您关于 segue 假定硬连接的建议是不准确的。可以构建一个 segue，在接收端编程为协议(protocol)实现，而不是特定类。这是完全合法的，并且使您的代码更加灵活。

Is there any other reasons to use segue and delegate pattern?

按照设计，segue API 不是对称的:当 segue 即将触发时，发送方会收到通知，但接收方只是被打开。因此，发送方的任务是将所需的任何内容传递给接收方，以建立一种方式使其与发送方通信。

If delegate is so nice, why not use 2 delegates for all data passing and messaging?

您完全可以使用委托(delegate)来与双方进行沟通。然而，API 的不对称性使得它没有必要使用第一个委托(delegate)。