故事板设计模式（分享或不分享）

Question

这可能在很大程度上是优惠的，但我想知道是否有任何理由以这种或那种方式作出决定。

在使用故事板进行设计时，您总是会遇到许多视图控制器。我正在研究严格的MVC方法的开销，其中每个控制器都在其自己的UIViewController子类中实现，并具有相应的UIView子类（甚至是MVVM的视图模型类），这似乎很快失控 - 它需要时间将几十个文件添加到项目中（许多文件功能很少）。另一种方法是将所有视图链接到代表所有故事板功能的公共控制器。

我倾向于如果你没有任何单独的视图控制器的实质控制器代码，那么将它们全部组合成一个不应该损害代码的可读性（并且可能会增加它而不是添加大量的源文件）。另一方面，如果您具有为任何特定视图控制器实现的重要功能，那么它应该封装在它自己的控制器中。

在大多数情况下，我会将所有控制器构建为尽可能可重用（封装在自己的自定义UIViewController子类中）。故事板把它放在一个有趣的角度，因为它们似乎是针对通常只有很少入口点的视图序列。

Answer 1

你的想法是正确的

• 如果您在每个VC（ViewController）中没有太多功能，他们会将您的所有代码合并到一个VC中。这种方法的唯一缺点是您将无法实现特定于视图的代码，并且您将使用此公共VC的每个视图将执行相同的代码，无论其是否需要。例如viewWillAppear等中的代码
• 同样，如果您拥有特定视图的大量功能，那么最好将其置于自己的VC
之下
• 这只是一个建议，如果您需要在多个VC之间使用一些通用代码逻辑，而不是在相同代码的每个VC中进行复制和粘贴，请将其转换为Category类型的方法，然后在任何地方调用它它需要。因此，仅在1处更改代码。

更多风险投资并不一定意味着糟糕的设计。在我看来，这种方式更容易维护。我的两分钱。 ： - ）

Answer 2

故事板中的每个场景都应该有自己的UIViewController子类。即使这样做，也很容易获得巨大的不可维护的视图控制器（MVC = Massive View Controller）。将多个场景的所有代码放在同一个视图控制器中会产生更大的代码并违反单一责任原则。每个班级应该只做一件事。

这也意味着您不应将常用功能复制到所有UIViewController子类中。然后他们又会做多件事 - 常见的东西和他们的实际目的。相反，您可以将公共代码放在其他控制器对象（不是UIViewController的后代）中，并在视图控制器中使用它们。

根据用例，公共基类也可以使用，但总是更喜欢使用组合而不是继承。

其他控制器对象的另一个好处是，您还可以直接在Interface Builder中添加它们，并将操作和出口连接到它们。您的主视图控制器类通常甚至不必知道它们存在。