NSHipster 解析：NSOrderedSet 的设计哲学与使用场景

在 Cocoa 开发中，集合类型是基础中的基础。今天我们要深入探讨的是一个特殊的集合类型：NSOrderedSet。这个类型看似简单，却蕴含着 Cocoa 框架设计的深层思考。

为什么 NSOrderedSet 不是 NSSet 的子类？

初看 NSOrderedSet，它似乎应该继承自 NSSet —— 它保持了 NSSet 的元素唯一性特性，同时增加了类似 NSArray 的有序访问能力（如 objectAtIndex: 方法）。按照里氏替换原则，这似乎完全合理。

但现实是：NSOrderedSet 直接继承自 NSObject，而非 NSSet 或 NSArray。这背后隐藏着 Objective-C 类簇（Class Cluster）设计模式与可变/不可变类对（Mutable/Immutable Pair）的深层限制。

类簇与可变性带来的设计挑战

类簇是 Foundation 框架的核心设计模式之一，它通过隐藏具体实现类来提供简洁的接口。但这种简洁性是以扩展性为代价的，特别是在处理可变/不可变类对时。

考虑 -mutableCopy 方法的预期行为：

NSSet* immutable = [NSSet set];
NSMutableSet* mutable = [immutable mutableCopy];

mutable 对象应该同时是 NSSet 和 NSMutableSet 的实例。如果 NSOrderedSet 继承自 NSSet，那么：

NSOrderedSet* immutable = [NSOrderedSet orderedSet];
NSMutableOrderedSet* mutable = [immutable mutableCopy];

这时 mutable 是 NSSet 的实例，但不是 NSMutableSet 的实例，这会导致它无法作为需要 NSMutableSet 类型参数的方法的输入。

如果尝试让 NSMutableOrderedSet 同时继承 NSMutableSet，又会导致它不再是 NSOrderedSet 的实例。这种矛盾在 Objective-C 的单继承模型下无法调和。

协议（Protocol）是解决方案吗？

理论上，我们可以通过协议来解决这个问题：

• NSArray : NSObject <NSOrderedCollection>
• NSSet : NSObject <NSUniqueCollection>
• NSOrderedSet : NSObject <NSOrderedCollection, NSUniqueCollection>

但这种方案需要重构整个 Foundation 框架的 API，将所有接收 NSArray 的参数改为接收 id <NSOrderedCollection>。这种改动成本极高，且可能引入大量边缘情况。

NSOrderedSet 的正确使用场景

NSOrderedSet 最初是随着 iOS 5 和 OS X Lion 引入的，主要是为了解决 Core Data 中关系集合的有序性问题。在此之前，开发者需要通过添加 position 属性来手动维护顺序，这种方式既繁琐又容易出错。

对于大多数 API 设计场景：

1. 如果只是简单地传递对象集合，使用 NSArray 即可
2. 如果需要确保元素唯一性，使用 NSSet
3. 只有当同时需要有序性和唯一性时，才考虑 NSOrderedSet

最佳实践建议

作为一般规则：NSOrderedSet 适合作为中间表示和内部数据结构，但除非特别符合数据模型语义，否则不应将其作为方法参数类型。

通过理解 NSOrderedSet 的设计取舍，我们不仅能更好地使用这个类型，还能深入领会 Foundation 框架在简洁性和扩展性之间所做的权衡。这种理解将帮助我们做出更明智的 API 设计决策。