而不是使用一个应用程序代理，以使的UIApplication单可致电预定时间的委托方法，有什么的只是继承的优点和缺点UIApplication ？ （ 更新：为什么iOS的架构使用的应用程序委托，而不是让人们写通过继承应用程序UIApplication ？并覆盖其各种方法）
这是因为当我们创建一个新UIView控制，我们的子类UIView （ 更新：要不我们继承UIViewController太）。 那么，为什么应用程序的情况下，我们不继承UIApplication但使用委托呢？
再次，从文档：
子类注意事项
您可能决定继承的UIApplication覆盖的SendEvent：或sendAction：到：来源：forEvent：实现自定义的事件和行动调度。 然而，很少有一个有效的需要扩展此类; 应用程序委托（UIApplicationDelegate是足以满足大多数场合。如果你继承的UIApplication，非常肯定你正在试图与子类来完成的。
从UiApplication类参考：
UIApplication类提供控制和协调iOS上运行的应用程序的一个集中点。
每个应用程序都必须拥有的UIApplication的只有一个实例（或UIApplication的一个子类）。 当一个应用程序启动时，UIApplicationMain函数被调用; 在它的其他任务，这个函数创建一个单独UIApplication对象。 此后，你可以通过调用sharedApplication类方法访问该对象。
所以，你是什么意思“的意思是，我们为什么不继承的UIApplication？苹果甚至提供了如何在子类实现笔记。
至于你提到的代表团及以上只是标准类单使用的问题，答案很简单：一个应用程序必须提供一个常见的方式收到和调度事件（包括外部和系统有关），处理多任务，并且接口与系统松散（这是为什么main.m文件包括到应用程序委托的引用）。
究其原因开发商通常不就是因为没有必要。 UIApplication的工作，它需要为大多数情况下。 它只是需要在某些预定情况下该怎么做一些提示（这就是为什么它有一个代表）。 UIView的，而另一方面，是非常通用的，我不认为这是以往任何时候都原样使用。 这可能是在所有iOS的世界上最定制类。
代表团是一个核心的设计模式。 它允许职责的程序的部件之间的政企分开。 我们的想法是，你的程序的一部分，例如，绘制到屏幕上可能不应该说你的数据库。 有几个原因：
性能：如果绘制到屏幕上的相同的对象访问您的数据存储，你会遇到性能问题。 期。 句号。
保养的代码：它更容易概念化是正确的模块化的代码。 （对于我来说，反正）
灵活性：如果您在代码中继承，这是伟大的 - 直到你开始运行到有各种各样的意外的行为，单片类。 你会到达，你必须超载行为，把事情偏了点，和你的财产的命名空间可以变得污浊。 尝试类别，delegatation，并为替代块。
这就是说，我确实碰到的情况是子类是适当的。 我有一个信息亭应用中，我想自动解散了一定的设置菜单，如果没有与之交互一段时间。 要做到这一点，我必须有访问整个应用程序的触摸事件。 我子类UIApplication和压倒sendEvent: 这是适当的话，虽然这是一个边缘的情况下。 所罗门王在传道书说，转述：有对一切在阳光下的时间和地点。
为了便于书写，阅读，在迭代，并保持你的程序，我们强烈建议您遵循某些做法。 欢迎你继承很多类，而苹果是不会拒绝你的应用程序的代码很差，只要它运行作为标榜。 也就是说，如果你不特定的尝试和真正的实践，你自掘坟墓遵守。 子类本身不是坏事，但类别，协议和块是如此迷人，我宁愿他们无论如何。
有很多，一个UIView子类可能需要做专业的事。 想UIScrollView中，UIImageView的，一个UIWebView等，以及如何彻底不同其内部运作的必须。 但尽管如此，他们必须参加视图层次等子类是有道理的。
UIApplication的，在另一方面，是应用程序级事件，通知，打开网址，访问窗口和其它通用的东西的中心毂。 在正常情况下，一个应用程序应该真的只需要知道的事情， UIApplicationDelegate协议提供。
从A音符的UIApplication概述说明一个道理，你可以继承的UIApplication：
您可能决定继承的UIApplication覆盖的SendEvent：或sendAction：到：来源：forEvent：实现自定义的事件和行动调度。 然而，很少有一个有效的需要扩展此类; 应用程序委托（UIApplicationDelegate是足以满足大多数场合。如果你继承的UIApplication，非常肯定你正在试图与子类来完成的。
但是，这应该只非常特殊的情况下是必要的。
