Objective-C中的对象层次结构

Question

我已经被介绍到具有〜50,000 LoC的Objective-C代码库，并且我估计25％左右是重复代码。 不幸的是，到目前为止，在代码库中，面向对象的原理一直被忽略，而采用了复制和粘贴逻辑。 好极了！

我来自Java背景，许多此类重复可以通过良好的老式面向对象编程来解决。 在很多情况下，将共享逻辑提取到基类中似乎是正确的解决方案。

但是，在我开始创建一堆基类并在派生类之间共享通用逻辑之前，我认为我应该停下来看看是否有其他可用的选择。 在观看了Ken Kocienda从2011年开始的WWDC的“编写易于更改的代码”会议之后，他建议我将对象层次结构保持尽可能浅。 他没有就他为什么有这种观点提供任何确切的统计数据，所以我想知道我是否错过了某些东西。

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

而且，从运行时性能的角度来看，有什么可以让我远离创建对象层次结构的吗？

Answer 1

我有段时间想起从其他背景 （包括Java） 进入iOS的想法。 由于ARC，某些情况已更改。 特别是，内存管理不再是中心问题。 也就是说，您过去为简化内存管理所做的所有事情（使用访问器，使用访问器，使用访问器）在ARC中同样有效。

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

查看UITableView及其对委托和数据源的使用。 看一下像NSAttributedString这样的东西，它是HAS-A NSString而不是IS-A。 这很常见，通常会使事情更清洁。 与所有大对象层次结构一样，始终要记住LSP 。 当有人忘记正方形不是矩形时，我会看到很多ObjC设计都是横行的。 同样，所有语言都是如此，但是在设计时值得记住。

只要使用不可变（值）对象，它们都是真正的胜利。

您很快就会发现的另一件作品是，很少有诸如“最终”或“受保护”之类的“安全装饰”（有@protected ，但实际上在实践中并没有那么有用，并且很少使用）。 来自Java和C ++背景的人们倾向于对各种访问规则的编译器强制执行感到烦恼。 ObjC没有大多数保护措施的编译器实施（您始终可以在运行时将所需的任何消息发送给任何对象）。 您只需要使用一致的命名约定，就可以随意使用私有方法。 程序员纪律代替了编译器强制。 实际上，它在大多数情况下都可以正常工作。

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

我从对象层次结构的特定问题中走了一些步，但希望它会有用。

Answer 2

Objective-C中的深层次结构的一个主要问题是Xcode根本无法帮助您理解/管理它们。 另一个简单的原因是，Objective-C中的几乎所有东西都比Java中的东西复杂了两倍，因此您需要更加努力地使事情变得简单。

但是我发现Objective-C中的合成很尴尬（尽管我不能确切地说出原因），因此没有“完美”的答案。

我已经观察到，在Objective-C和Java中，小的子例程要少得多，而且人们更可能看到在大多数相同的视图控制器等之间重复的代码。 我认为其中很大一部分只是开发工具和创建新类的相对尴尬。

PS：我不得不重做一个包含大约55K行的应用程序，这与我们可以估计的接近。 如您所见，可能有大约25％的重复，但是还有25％左右的完全无效代码。 （值得庆幸的是，此应用自此以来已被废弃。）