为什么子类不受欢迎？

Question

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

以同样的方式我问自己：为什么不能直接访问键盘才能解雇它？为什么需要将视图控制器作为委托发信号以便辞职第一响应者？

Answer 1

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

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

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

3. 灵活性：如果您在代码中进行了子类化，那就太好了 - 直到您开始遇到具有各种不良行为的单片类。您将达到必须重载行为以关闭事物的程度，并且您的属性命名空间可能会受到污染。尝试使用altrnatives的类别，委托和块。正如所罗门王在传道书中所说的那样，释义：阳光下的一切都有时间和地点。

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

Answer 2

  

为什么子类化不受欢迎？

子类化不是不可取的。只是它并不总是正确的解决方案，而且通常使用组合而不是继承更好。已经在Stack Overflow上写了很多关于你的标题，以至于你的标题使这个问题有被复制的危险。我只想指出一个涉及这个主题的更受欢迎的问题，而不是试图重复：Prefer composition over inheritance?

  

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

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

Answer 3

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

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