ios - 为什么子类化是不可取的？

Question

为什么 UIApplication 类需要一个委托来代表它完成“事情”？为什么这个类不能直接做“事情”而不需要像委托这样的中间对象？该原则的目的是什么？

同样我问自己：为什么不能直接访问键盘来关闭它？为什么需要将视图控制器作为委托发送信号以便让第一响应者辞职？

Answer 1

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

1. 性能：如果绘制到屏幕的同一个对象访问您的数据存储，您将遇到性能问题。时期。句号。

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

3. 灵活性：如果您在代码中进行子类化，那就太好了——直到您开始遇到具有各种不良行为的单体类。您将达到必须重载行为以关闭事物的地步，并且您的属性命名空间可能会被污染。尝试替代方案的类别、委托和块。正如所罗门王在传道书中所说的那样，意译：太阳底下的一切都有时间和地点。

为了更容易编写、阅读、迭代和维护您的程序，强烈建议您遵循某些做法。欢迎您对许多类进行子类化，Apple 不会因为您的应用程序代码不佳而拒绝您的应用程序，只要它按照宣传的方式运行即可。也就是说，如果你不遵守经过实践检验的具体做法，你就是在自掘坟墓。子传递本身并不是坏事，但类别、协议和块是如此迷人，我还是更喜欢它们。

Answer 2

为什么子类化是不可取的？

子类化不是不可取的。只是它并不总是正确的解决方案，而且使用组合而不是继承通常更好。已经在 Stack Overflow 上写了很多关于此的内容，以至于您的标题使这个问题面临被重复关闭的危险。与其试图重复，我将只指出涵盖该主题的一个更流行的问题：更喜欢组合而不是继承？

为什么 UIApplication 类需要一个委托来代表它完成“事情”？为什么这个类不能直接做“事情”而不需要像委托这样的中间对象？该原则的目的是什么？

它提供了更松散的耦合，允许 Apple 在不破坏现有代码的情况下更改或替换应用程序对象。

Answer 3

代表非常有用，但他们也有自己的位置和时间。不使用委托也很有可能进行。但是，在某些情况下，代表很重要。例如，当您使用 uiTextview 委托时，控制类知道文本何时更改以便处理它很重要。而且，由于不同的类可能希望以不同的方式处理此事件（限制字符、大写字母等），因此最容易使用委托。

您可能会说：是的，但为什么不创建一个具有所需行为的子类呢？好吧，这是可能的，但是有几个原因可以说明您不应该这样做。首先，您可以覆盖在调用委托之前发生的行为。接下来，它可能很危险，因为您可能会意外覆盖必要的功能。第三，它需要更多的工作和更多的代码，因此会更难调试。想象一下，您有一个包含 100 个文本框的表单，它们都有不同的行为。你不会想要创建 100 个子类......它更容易做一个 switch 案例并适当地委托。