为什么不将UIApplication子类化？为什么要使用代表？

Question

不是使用应用程序委托，以便UIApplication单例可以在预定义的时间调用委托方法，只是继承UIApplication的优点和缺点是什么？ （更新：为什么iOS体系结构使用应用程序委托而不是让人们通过继承UIApplication并覆盖其各种方法来编写应用程序？）

那是因为当我们创建一个新的UIView控件时，我们会继承UIView（更新：或我们子类UIViewController）。那么为什么对于应用程序的情况，我们不是子类UIApplication而是使用委托代替？

Answer 1

再次，从文档：

  

子类注释

     

您可能决定将UIApplication子类化为覆盖sendEvent：或   sendAction：to：from：forEvent：实现自定义事件和操作   调度。但是，很少有必要扩展它   类;应用程序委托（UIApplicationDelegate就足够了）   在大多数情况下。如果你做UIApplication的子类，那就非常肯定了   你想要用子类完成什么。

Answer 2

来自UIApplication Class Reference:

  

UIApplication类为在iOS上运行的应用程序提供集中的控制和协调点。

     

每个应用程序必须只有一个UIApplication实例（或UIApplication的子类）。启动应用程序时，将调用UIApplicationMain函数;在其他任务中，此函数创建一个单独的UIApplication对象。此后，您可以通过调用sharedApplication类方法来访问此对象。

那你的意思是“我们为什么不将UIApplication子类化？Apple甚至提供了关于在子类中实现什么的注释。

关于仅使用标准类的委托和单例使用的问题，答案很简单：应用程序必须提供一种通用方式来接收和分派事件（外部和系统相关），处理多任务处理，以及松散地与system（这就是为什么main.m包含对你的app委托的引用）。

Answer 3

开发人员通常不喜欢的原因是因为没有必要。 UIApplication适用于大多数情况。它只需要一些关于在某些预定义情况下做什么的提示（这就是为什么它有一个委托）。另一方面，UIView是非常通用的，我不认为它是按原样使用的。它可能是所有iOS世界中最自定义的类。

Answer 4

委托是一种核心设计模式。它允许在程序的各个部分之间分离责任。这个想法是你的程序的一部分，例如，绘制到屏幕可能不应该与您的数据库交谈。这有几个原因：

性能：如果绘制到屏幕的同一对象访问您的数据存储，您将遇到性能问题。期。完全停止。

代码维护：更容易概念化正确模块化的代码。 （对我来说，无论如何）

灵活性：如果您在代码中进行了子类化，这很好 - 直到您开始遇到具有各种不良行为的单一类。您将达到必须重载行为以关闭事物的程度，并且您的属性命名空间可能会受到污染。尝试使用类别，委托和替代方案块。

那就是说，我确实遇到了子类化合适的情况。我有一个自助服务终端应用程序，如果它在一段时间内没有与之交互，我想自动关闭某个设置菜单。为此，我必须能够访问整个应用程序中的触摸事件。我将UIApplication分组并覆盖sendEvent:。那是合适的，尽管这是一个优势。正如所罗门王在传道书中所说的那样，释义：阳光下的一切都有时间和地点。

为了便于编写，阅读，迭代和维护您的程序，强烈建议您遵循某些做法。欢迎您继承许多类的子类，Apple不会拒绝您的应用程序以查找代码不佳的内容，只要它按照宣传的方式运行即可。也就是说，如果你不遵守特定的尝试和真实的做法，你就是在挖掘自己的坟墓。子类化本质上并不坏，但类别，协议和块是如此迷人，无论如何我更喜欢它们。

Answer 5

UIView子类可能需要做很多专门的事情。想想UIScrollView，UIImageView，UIWebView等，以及它们的内部工作方式必须有多么不同。但是，他们仍然必须参与视图层次结构，因此子类化是有意义的。

另一方面，UIApplication是应用程序范围事件，通知，打开URL，访问窗口和其他常规事物的中心枢纽。在正常情况下，应用程序应该只需要知道UIApplicationDelegate Protocol将提供的内容。

来自UIApplication Overview的注释解释了您可能将UIApplication子类化的一个原因：

  

您可能决定将UIApplication子类化为覆盖sendEvent：或sendAction：to：from：forEvent：以实现自定义事件和操作分派。但是，很少有必要扩展这个类;应用程序委托（UIApplicationDelegate在大多数情况下都足够了。如果你做UIApplication的子类，那么要非常确定你要用子类完成什么。

但这只应该在非常特殊的情况下才有必要。

Answer 6

我将添加没有其他提及的内容：当通过委托方法实现而不是具有覆盖方法的子类覆盖/增强/添加行为时，委托消除了对super的调用。我已经看到许多开发人员简单地忘记了调用super来回答自己的Stackoverflow问题（甚至在某些人甚至发布了可能的答案之后）。较新的方法装饰器NS_REQUIRES_SUPER通过警告开发人员警告（希望他们不会忽略它）来帮助解决此问题（希望超级调用的顺序很重要）。我认为Apple认为让开发人员改为实现委托对象是没有错误的，它没有调用超级要求，并且他们甚至还辛苦地将UIResponder方法从UIApplication转发到委托对象。