iphone - Objective-C 中的对象层次结构

Question

有人向我介绍了一个 Objective-C 代码库，它有大约 50,000 个 LoC，我估计有 25% 左右是重复代码。不幸的是，到目前为止，OO 原则在代码库中大多被忽略，而倾向于复制和粘贴逻辑。耶!

我来自 Java 背景，很多这种重复可以通过良好的老式面向目标的编程来解决。在很多情况下，将共享逻辑提取到基类中感觉像是正确的解决方案。

但是，在我着手创建一堆基类并在派生类之间共享公共(public)逻辑之前，我想我应该停下来看看是否还有其他可用的选择。在观看了 2011 年 Ken Kocienda 的“编写易于更改的代码”WWDC session 之后，他建议我保持对象层次结构尽可能浅。他没有提供任何确凿的统计数据来说明他为什么会有这种观点，所以我想知道我是否遗漏了什么。

无论如何我都不是 Objective-C 专家，所以我想知道在决定对象层次结构时是否有任何最佳实践。基本上，我想就您何时决定停止创建基类并开始使用组合而不是继承作为类之间共享代码的方式征求意见。

此外，从运行时性能的角度来看，有什么可以阻止我创建对象层次结构吗？

Answer 1

我在 coming to iOS from other backgrounds 上写了一些想法，包括 java 。由于 ARC，有些事情发生了变化。特别是，内存管理不再那么重要。也就是说，您过去为简化内存管理所做的所有事情(使用访问器，使用访问器，使用访问器)在 ARC 中仍然同样有效。

@Radu 是完全正确的，您应该经常保持您的类层次结构相当简单和浅(如您阅读的那样)。在 Cocoa 中，组合通常是一种比广泛的子类化更好的方法(这在 Java 中也可能是正确的，但在 ObjC 中是常见的做法)。 ObjC 也没有抽象方法或类的概念，这使得某些类型的子类化有点尴尬。与其将共享逻辑提取到基类(尤其是抽象基类)中，不如将它们提取到单独的策略对象中。

查看 UITableView 及其对委托(delegate)和数据源的使用。查看像 NSAttributedString 这样的东西，它有一个 NSString 而不是 IS-A。这很常见，而且通常会让事情变得更干净。与所有大型对象层次结构一样，保留 LSP时刻记在心里。当有人忘记 a square is not a rectangle 时，我看到很多 ObjC 设计都偏离了方向.同样，所有语言都是如此，但在设计时值得记住这一点。

只要您可以使用不可变(值)对象，它们就是真正的胜利。

另一件你很快就会发现的是，很少有像“final”或“protected”这样的“安全装饰”(有一个@protected，但它实际上并没有那么有用在实践中很少使用)。具有 Java 和 C++ 背景的人往往会担心编译器对各种访问规则的强制执行。 ObjC 没有大多数保护的编译器强制执行(您始终可以在运行时向任何对象发送您想要的任何消息)。您只需使用一致的命名约定，不要四处寻找私有(private)方法。程序员纪律取代了编译器强制执行。实际上，在绝大多数情况下，它都可以正常工作。

也就是说，ObjC 有很多警告，您绝对必须消除所有警告。大多数 ObjC 警告实际上是错误。

我稍微偏离了对象层次结构的具体问题，但希望它有用。