故事板设计模式（分享或不分享）
Storyboard design pattern (to share or not to share)
这可能在很大程度上是优惠的，但我想知道是否有任何理由就此做出决定。
在使用故事板进行设计时，您总是会得到许多视图控制器。我正在研究严格的 MVC 方法的开销，其中每个控制器都在其自己的 UIViewController subclass 中实现，并具有相应的 UIView subclass（甚至是 MVVM 的视图模型 class），这似乎很快就失控了——向项目添加几十个文件（许多文件功能很少）不需要时间。另一种方法是 link 所有视图到代表所有故事板功能的公共控制器。
我的倾向是，如果您没有任何单独的视图控制器的大量控制器代码，那么将它们全部组合成一个应该不会损害代码的可读性（并且可能会增强它超过添加大量源文件）。另一方面，如果你有重要的功能要为任何特定的视图控制器实现，那么它应该封装在它自己的控制器中。
在大多数情况下，我会构建尽可能可重用的所有控制器（封装在它们自己的自定义 UIViewController 子classes 中）。故事板将这一点放在一个有趣的角度，因为它们似乎适用于通常很少有入口点的视图序列。
你的想法是正确的
- 如果每个 VC (ViewController) 中的功能不多，他们会将您的所有代码合并为一个 VC。这种方法的唯一缺点是您将无法实现特定于视图的代码，并且您将使用此公共 VC 的每个视图都将执行相同的代码，无论是否需要。例如viewWillAppear 等中的代码
- 同样，如果您对特定视图有很多功能，那么最好将其放在自己的下面 VC
- 这只是一个建议，如果您需要在多个 VC 之间使用一些通用的代码逻辑，那么与其在每个 VC 中复制和粘贴相同的代码，不如将其制作成Category 类型的方法，然后在需要的地方调用它。所以只改1个地方的代码。
更多 VC 并不一定意味着糟糕的设计。在我看来，这样更容易维护。我的两分钱。 :-)
故事板中的每个场景都应该有自己的 UIViewController 子class。即使这样做，也很容易获得无法维护的巨大视图控制器（MVC = Massive View Controller）。将多个场景的所有代码放在同一个视图控制器中会创建更大的视图控制器，并且还会违反单一职责原则。每个 class 应该只做一件事情。
这也意味着您不应该将通用功能复制到所有 UIViewController 子class中。然后他们又会做很多事情——共同的事情和他们的实际目的。相反，您可以将您的公共代码放在其他控制器对象（不是 UIViewController 的后代）中，并在您的视图控制器中使用它们。
根据用例，公共基础 class 也可以工作，但使用组合而不是继承总是更可取。
关于其他控制器对象的另一个好处是，您还可以直接在 Interface Builder 中添加它们，并将操作和插座连接到它们。您的主视图控制器 class 通常甚至不需要知道它们的存在。
这可能在很大程度上是优惠的，但我想知道是否有任何理由就此做出决定。
在使用故事板进行设计时，您总是会得到许多视图控制器。我正在研究严格的 MVC 方法的开销，其中每个控制器都在其自己的 UIViewController subclass 中实现，并具有相应的 UIView subclass（甚至是 MVVM 的视图模型 class），这似乎很快就失控了——向项目添加几十个文件（许多文件功能很少）不需要时间。另一种方法是 link 所有视图到代表所有故事板功能的公共控制器。
我的倾向是，如果您没有任何单独的视图控制器的大量控制器代码，那么将它们全部组合成一个应该不会损害代码的可读性（并且可能会增强它超过添加大量源文件）。另一方面，如果你有重要的功能要为任何特定的视图控制器实现，那么它应该封装在它自己的控制器中。
在大多数情况下，我会构建尽可能可重用的所有控制器（封装在它们自己的自定义 UIViewController 子classes 中）。故事板将这一点放在一个有趣的角度，因为它们似乎适用于通常很少有入口点的视图序列。
你的想法是正确的
- 如果每个 VC (ViewController) 中的功能不多，他们会将您的所有代码合并为一个 VC。这种方法的唯一缺点是您将无法实现特定于视图的代码，并且您将使用此公共 VC 的每个视图都将执行相同的代码，无论是否需要。例如viewWillAppear 等中的代码
- 同样，如果您对特定视图有很多功能，那么最好将其放在自己的下面 VC
- 这只是一个建议，如果您需要在多个 VC 之间使用一些通用的代码逻辑，那么与其在每个 VC 中复制和粘贴相同的代码，不如将其制作成Category 类型的方法，然后在需要的地方调用它。所以只改1个地方的代码。
更多 VC 并不一定意味着糟糕的设计。在我看来，这样更容易维护。我的两分钱。 :-)
故事板中的每个场景都应该有自己的 UIViewController 子class。即使这样做，也很容易获得无法维护的巨大视图控制器（MVC = Massive View Controller）。将多个场景的所有代码放在同一个视图控制器中会创建更大的视图控制器，并且还会违反单一职责原则。每个 class 应该只做一件事情。
这也意味着您不应该将通用功能复制到所有 UIViewController 子class中。然后他们又会做很多事情——共同的事情和他们的实际目的。相反，您可以将您的公共代码放在其他控制器对象（不是 UIViewController 的后代）中，并在您的视图控制器中使用它们。
根据用例，公共基础 class 也可以工作，但使用组合而不是继承总是更可取。
关于其他控制器对象的另一个好处是，您还可以直接在 Interface Builder 中添加它们，并将操作和插座连接到它们。您的主视图控制器 class 通常甚至不需要知道它们的存在。