0

我继承了一个长期维护代码库，它有两种截然不同的 iPhone 和 iPad 视图。这已经创建了一个大型 UIViewController 类，该类已经膨胀到超过 1k 行代码，是 ISIPAD 语句、私有变量、属性、iBOutlets/Actions 的混搭，例如，将 UITableView 用于一种实现，而另一种则完全不同。

更糟糕的是，当前的软件模式依赖于子类化。

目前我们看起来像这样：

ParentVC (both iphone/ipad God class also has xib(xib~ipad) + iboutlets/actions)
      |         |            |
    ChildA    ChildB       ChildC

我最初的想法是采用 ParentVC 并将其拆分为 iPhone/iPad 特定的类

               ParentVCBase
         |                     |
     ParentVC_iPad(xib~ipad)  ParentVC_iPhone(xib)
         |                       |
   ChildA/B/C_iPad         ChildA/B/C_iPhone

并通过工厂调用吐出正确的 Child 子类。

我遇到的问题是每个 Child 重写了一些 ParentVC 方法调用并实现了它自己的非设备特定的功能特定方法（请记住，原始子类化的主要目标是共享视图布局）。这种设计模式只有在我为 ChildA_iPhone 和 ChildB_iPad 复制代码时才有效。我宁愿避免这种情况，因为我已经将一种反模式换成了另一种。

我在这里有点茫然。我几乎考虑过在运行时创建 Child 类（objc/runtime.h），从引用 Child 类中调配所需的 Child 方法，但这似乎并不比我们目前所拥有的要少。为了简单地清理，我还考虑保留 ParentVC 标头（包含大量 IBOUTlet、属性等）并将特定于设备的方法分类以至少将功能分开，直到需要真正重构的那一天。

好奇是否有任何 iOS 架构师不得不在某个时间点处理这个问题，或者他们可能如何处理它。

4

1 回答 1

0

这不是一个 iOS 特定的问题，而是一个面向对象的设计问题。

您肯定希望避免代码重复。重复是许多罪恶的根源。

通常，您要做的是避免在设计类时受到继承限制的限制。你想要走向的是班级组成。

因此，您可以使用桥接模式移至如下所示的设计：

  ParentVC           --->             ImplementationA
   |    |                               |            |
ChildA ChildB                 Implementation_iPhone Implementation_iPad

在这里，ParentVC 具有与上面相同的类层次结构，但它使用单独的类层次结构 ImplementationA 来实现。该类层次结构分解为 iPhone 和 iPad 版本。类 ImplementationA 包含 ParentVC 中实现的核心。

继承是一种设计模式，但它只是众多设计模式中的一种。如果你坚持只使用一种模式，你就会陷入糟糕的设计。您需要组合模式以正确建模系统。

当然，请务必尽可能使用单元测试，以确保在进行这些更改时不会破坏任何内容。

于 2012-08-01T04:13:27.897 回答