Question

许多CocoaPod和本机iOS库使用他们命名为CustomClassDelegate或CustomClassDataSource的协议作为进行某些设置或自定义的方法。我想知道什么时候应该使用这个编程模型，因为看起来我可以通过属性完成大部分工作。

示例

如果我定义了一个名为SmurfViewController的自定义类SmurfLabel，那么最好将smurfLabel存储为私有属性并使用公共计算名为smurf的属性如下所示：

private var smurfLabel = UILabel()
public var smurf: String {
  get {
    return smurfLabel.text
  }
  set(text) {
    smurfLabel.text = text
  }
}

或者我应该定义一个具有如下公共函数的SmurfDataSource：

func textForSmurfLabel() -> String {
  return "smurfText"
}

我什么时候应该在这里使用什么？

Answer 1

你应该只使用一个属性。代理和数据源用于不同的控制器/对象，当替代方法是从navigationStack / view层次结构实例化控制器/对象时，它们彼此交谈。代表在两者之间形成一种特定的沟通方式，可以清楚地了解他们的关系，同时保持他们的分离（假设你试图保持这种方式）。我不同意那些说回调“更好”的文章。它们很棒，我建议经常使用它们，但是要明白，swift为您提供的大多数选项都有一个最适合它们的地方。

我可能略有偏见，但Swift是一种令人惊叹的语言，OOP是一个主干，它所拥有的一切都很好地组合在一起，以便为你自己所处的每种情况提供正确的工具。

我经常发现自己在我更高级的设置中使用这些工具和另一个更可自定义的选项，其中我有一个监督viewController来管理许多子控制器。它可以直接访问所有活跃的，但如果它的任何一个孩子与它通信，它是通过代表。它的主要工作只是处理它们在屏幕上的位置，所以我保持一切都可管理。

Answer 2

委托和数据源更适合将行为卸载到其他实体，而不是简单的值。换句话说，如果你的类型只需要某个值的某个值，那么将它作为可以从客户端代码设置的属性公开更为合理。

但是当用户点击特定的表格视图单元格时，应该发生什么（例如）是不应该硬编码到UITableView中的行为。相反，为了灵活性，可以在委托中创建该行为的任何实现，并在适当时由UITableView调用。

通常，将委托视为一种不必使子类化的方法，因为通常在子类中重写的方法会转移到可以由任何类型实现的协议中，而不仅仅是基类型的子类。而不是调用内部实现的方法来获取某些行为，您的类型只是在外部协作类（委托）上调用这些行为。

因此，关于何时使用数据源或委托的最佳准则可能是：＆＃34;我是否需要继承此类以便在将来更改此值或行为＆＃34;。如果答案是否定的，因为您只需从客户端代码设置属性，就不要使用委托。如果答案是肯定的，那么将该行为卸载到委托或数据源，而不是强迫未来的程序员继承您的类，使其适用于他们的用例。

Answer 3

Delegate是未定义活动的接口。因此，当您创建SDK或框架时，您必须提供一个接口，以便用户可以为接口的预期活动编写适当的代码。

，表视图需要一个数据源来显示它的内容，但苹果的库开发人员不知道他们的库用户将使用的内容。所以他们提供了像datasource，delegate这样的接口。在图书馆里，他们只是称这种方法。这就是图书馆的制作方式。

但是在您的代码中，标签的定义非常明确，并且在当前视图中定义，并且您不需要为未定义的活动创建接口。

如果你想了解更多关于这种编码风格的信息，你需要对软件设计模式进行一些研究。

https://en.wikipedia.org/wiki/Observer_pattern

https://en.wikipedia.org/wiki/Delegation_pattern

https://en.wikipedia.org/wiki/Software_design_pattern

我非常喜欢苹果公司的sdk，因为他们非常正确地使用了所有需要的设计模式。

iOS：何时使用委托/数据源（协议）与属性

3 个答案: