ios - UIViewController 有多邪恶？

Question

这是一个关于 UIViewController 类及其在 iOS 应用程序中的适当角色的开放式问题。

我最近读了this article ，我部分同意作者的观点。与您的 View 和模型相关的每一点逻辑都不会最终被转储到 UIViewController 中显然很重要，但是单独构建所有 View 并使用委托(delegate)方法似乎有点极端访问操作。

我很好奇哪种设计在应用程序的内存和性能方面最有效(在处理移动应用程序时显然是一个重要的考虑因素)？正如帖子的作者指出的那样，Apple 似乎并不强烈反对将逻辑放在 UIViewController 中。

最终，我想知道正确的做事方式。那么问题来了， View 和与之相关的任何逻辑是否应该完全从VC中分离出来？我真的应该使用委托(delegate)与 UIViewController 通信吗？

Answer 1

View Controller 本质上并不是邪恶的，尽管它们发展成单一的困惑是很常见的，因为它们扩展起来非常方便。

…it seems a bit extreme to build all of your views separately and use delegate methods to access the actions.

将其视为将您的程序分解成更小的单元，无论它们是什么。在每种情况下都对 UIView 进行子类化并不是最好的解决方案(举一个例子)。

每个开发人员的容忍度都略有不同，并且因程序/案例而异，但识别和消除重复代码以及将您的程序分解为更小的单元非常容易。

我认为大多数类:

• 不应超过几个 ivar(例如 2)
• 不应超过 100 行
• 应该支持组合而不是继承。在许多您认为需要继承的情况下，可以使用协议(protocol)。

当然会有异常(exception)。

I'm curious about which design is most efficient in regards to the memory and performance of the app (clearly an important consideration when dealing with mobile apps)?

更重要的是，通过编写更多可重用的程序，您会收获很多。将更多的时间和精力投入到这些可重用的设计中，减少重复代码，并关注质量。将性能和内存写到您的设计中，这是一个值得关注的问题。通常，与令人生畏的新编写的、未经充分测试的单一 VC 相比，这将带来巨大的胜利。

Ultimately, I'd like to know the right way of doing things. So the question is, should the views and any logic associated with it be completely separated out of the VC? Should I really be using delegates to communicate with the UIViewController?

过度简化:不，如果您消除冗余代码、在适用的情况下关注可重用性并确保您的单元/类保持低复杂性，您就不必走那么远。绝对可以，在它们成长为单体类之前解决这些问题，无论它们是 VC 还是其他类型。