随着应用中的对象变得越来越多，如何在对象间进行消息的发送或数据的通信就成为摆在我们面前的一个问题，这本质上还是一个架构问题。需要对代码的构建做些规划，使得代码能够各司其职，并且能在恰当的时刻根据需要共享信息。本章将会介绍一些系统性的思考方法，帮助你实现对象间的通信。
通信的问题常常可以归结为一个对象要能看到另一个对象：对象Manny要能找到对象Jack，这样才能够向Jack发送消息。
一个显而易见的解决办法就是将Jack作为Manny的一个实例属性值。这在Manny与Jack共享某些职责或彼此互为补充的情况下尤为有用。应用对象及其委托、表视图及其数据源、视图控制器及其所控制的视图，在这些情况中，前者都有一个指向了后者的实例属性。
这并不是说由于内存管理策略的问题（参见第12章），Manny需要声明为Jack的所有者，不过它是可以这么做的。对象不一定要保持其委托或数据源；与之类似，实现了目标－动作模式的对象（如UIControl）并没有保持其目标。通过使用弱引用以及将属性类型声明为Optional，然后以前后一致且安全的方式来对待这个Optional，Manny可以在不拥有Jack的情况下，让其假定对Jack的引用最终变为nil。另外，如果没有可控制的视图，那么视图控制器就是毫无意义的；当它有了视图后，它会保持这个视图，只有当视图控制器自身销毁时，它才会释放这个视图。
对象可以在没有彼此引用的情况下进行双向通信。其中一个对象拥有对另一个对象的引用就足够了，因为前者（作为向后者发送的消息的一部分）可以包含对自身的引用。
比如，Manny可能会向Jack发送消息，其中一个参数就是对Manny的引用；这仅仅构成了一种身份证明形式，或一种邀请形式，表示Jack自己的方法完成处理后，如果还需要进一步的信息，那么他可以向Manny发回消息。这样，Manny可以令自身对Jack处于暂时可见的状态；Jack不应该保持Manny（因为这显然会导致保持循环的风险）。另外，这还是一种常见的模式。委托消息textFieldShouldBeginEditing：的参数是个对发送消息的UITextField的引用。目标－动作消息的第1个参数就是个对发送消息的控件的引用。
不过，Manny一开始是如何获得对Jack的引用的呢？这是个重要的问题。iOS编程与面向对象编程的很重要的一个话题就是一个对象如何获得其他对象的引用。情况纷繁复杂，需要具体问题具体分析，不过还是存在着一些通用模式，本章就将介绍这些模式。
Manny可以通过一些方式向Jack发送消息，同时又不必直接发送给Jack，可能他都不知道或不关心谁是Jack。通知与KVO就是这样的，本章也将对其进行介绍。
最后，13.4节还将介绍这样一个问题：在典型的iOS程序中，什么样的对象需要彼此能够看到对方。