我已经介绍了一个Objective-C代码库,它有大约50,000 LoC,我估计25％左右是重复代码.不幸的是,在代码库中,OO原则在这一点上大多被忽略,有利于复制和粘贴逻辑.好极了！

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

但是,在我开始创建一堆基类并在派生类之间共享公共逻辑之前,我想我应该停下来看看是否还有其他可用选项.从2011年开始观看Ken Kocienda的“易于改变代码编写”WWDC会议之后,他建议我尽可能保持对象层次结构的浅薄.他没有提供任何关于他为什么有这个意见的严格统计数据,所以我想知道我是否错过了某些东西.

我不是任何想象力的Objective-C专家,所以我想知道在决定对象层次时是否有任何最佳实践.基本上,我想知道你何时决定停止创建基类并开始使用组合而不是继承作为在类之间共享代码的方式.

此外,从运行时性能的角度来看,有什么东西可以让我远离创建对象层次结构吗？

最佳答案 我在
coming to iOS from other backgrounds回忆了一些想法,包括Java.由于ARC,有些事情发生了变化.特别是,内存管理不再是前沿和中心.也就是说,您过去所做的所有使内存管理变得容易的事情(使用访问器,使用访问器,使用访问器)在ARC中仍然同样有效.

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

查看UITableView及其对委托和数据源的使用.看看像NSAttributedString这样的东西,它是HAS-A NSString而不是IS-A.这很常见,通常可以保持清洁.与所有大对象层次结构一样,始终牢记LSP.当有人忘记a square is not a rectangle时,我看到许多ObjC设计横着走.再一次,所有语言都是如此,但在设计时值得记住.

只要你可以使用它们,不可变(值)对象就是真正的胜利.

您将很快发现的另一件事是,很少有“安全装饰”,如“最终”或“受保护”(有一个@protected,但实际上并没有那么有用,很少使用).来自Java和C背景的人们倾向于担心编译器执行各种访问规则. ObjC没有大多数保护的编译器强制执行(您总是可以在运行时向任何对象发送任何消息).您只需使用一致的命名约定,不要去私有方法.程序员纪律取代了编译器执行.在实践中,它在绝大多数情况下都能正常工作.

也就是说,ObjC有很多警告,你绝对必须消除所有警告.大多数ObjC警告实际上都是错误.

我已经偏离了对象层次结构的具体问题,但希望它有用.