这是一个非常普遍的问题，但我今天想知道代表们。在这一点上，我并没有特定的时间使用它们或者不使用它们 - 除了明显的情况，例如从选择器或tableview中传递选择。例如，如果存在我可以传递对象周围的引用并使用它来调用方法的情况，是否有理由实现委托？总之，什么是在不使用它时最好使用的委托模式？
感谢您快速而全面的答案！他们都非常有帮助。
答案 0 :(得分：5)
委托模式的优点是委托对象与其委托之间的松散耦合。松散耦合提高了类在其他环境中的可重用性。
委托对象不必知道它与之通信的对象（除了它实现委托协议的要求） - 尤其不是它的类或它有什么方法。如果您以后想要在不同的上下文中重用您的组件或让它与另一个类的另一个对象进行通信，那么所有这个对象所要做的就是实现委托协议。委托对象根本不需要改变。
当然，这也有一个缺点，那就是需要更多代码，而且你编写的代码并不那么明确，因此可能有点难以理解。这种（通常很小的）权衡是否值得，取决于您的使用案例。如果两个对象无论如何都是紧密耦合的，并且将来重用的可能性很低，那么使用委托模式可能会有点过分。
答案 1 :(得分：3)
参见this讨论
委托允许一个对象在事件发生时将消息发送到另一个对象。
<强>赞成
非常严格的语法。所有要听的事件都有明确的定义 代表协议。
编译时警告/错误，如果某个方法没有按照代表的实施方式实现。
仅在控制器范围内定义的协议。
非常易于追踪，并且易于识别应用程序中的控制流程。
能够为多个协议定义一个控制器，每个控制器都有不同的代理。
维护/监控沟通过程无需第三方对象。
能够从被调用的协议方法接收返回值。这意味着代表可以帮助提供信息 到控制器。
<强>缺点
需要定义许多代码行：1。协议定义，2。控制器中的委托属性，以及3.委托本身内委托方法定义的实现。
在对象释放时需要小心将委托正确设置为nil，如果不这样做可能会通过调用解除分配对象上的方法导致内存崩溃。
虽然可能，但可能很困难，而且模式并不能真正让自己在控制器中拥有相同协议的多个委托（告诉多个对象有关同一事件）
答案 2 :(得分：2)
委托的“用例”与继承非常相似，即以多态方式扩展类行为。
这是wikipedia定义委派的方式：
在软件工程中，委托模式是面向对象编程中的设计模式，其中对象不是执行其声明的任务之一，而是将该任务委托给关联的辅助对象。存在一个责任倒置，其中一个辅助对象（称为委托）负责为委托者执行任务。委托模式是构成其他软件模式的基本抽象模式之一，例如组合（也称为聚合），混合和方面。
显然，委派和继承之间存在许多差异，但最大的一个是，IMO，继承是两个类之间的固定（又称编译时）关系，而委托可以在运行时定义（用支持这种语言的语言）。另一方面，继承提供了对多态性的更好支持。
委托是一个很大的主题（作为继承），你可以阅读很多相关内容。最后，决定是否使用委托或继承来决定是否需要“is-a”或“has-a”关系，因此列出选择指南并不容易。
对我而言，基本上，创建代表的决定来自以下观察：
我的代码提出了一组同质行为（这里的同构意味着可以被认为具有共同的“性质”）;
这些行为可能会针对特定情况“定制”（例如，替换为替代行为）。
这是我的个人观点，以及我对识别“委派”模式的方式的描述。这可能与我的编程规则充分了解重构原理这一事实有很大关系。
真的，IMO，委托是一种为你的班级定义“定制”点的方法。例如，如果您有某种抽象工作流程，那么在每个步骤中您都会根据某些条件采取某些操作;此外，那些具体的行动可以被另一种行为取代，然后我看到有机会通过授权重新使用。
希望这有帮助。