Cocoa/Objective-C 中有类似通用列表的东西吗？

Question

我真正喜欢 C# 的是通用列表。 只能包含一种类型的对象的列表。 Cocoa/Objective-C 中有类似通用列表的东西吗？ 到目前为止，我只知道 NSArray 会获取指向任何对象的指针。

Answer 1

在 Cocoa 应用程序中想要这样通常是设计薄弱的标志。

NSArray 是不可变的，因此它不会“获取指向任何对象的指针”，并且在交给您时可能已经包含正确的对象。 我认为您更担心的是 NSMutableArray ，您认为代码的其他部分可能会添加错误类型的对象。 但看看 Cocoa 本身； 在类设计中公开可变数组的情况非常罕见。

相反，您通常会公开一个 NSArray 和一些用于修改该数组的方法。 大致如下：

@class Foo : NSObject
- (NSArray *)bars;
- (void)addBar:(Bar *)bar;
- (void)removeBar:(Bar *)bar;
@end

这通常只需通过编译器警告即可阻止插入错误的对象，然后当然您可以在 -addBar: 和 -removeBar: 中添加断言如果你也愿意的话。

Answer 2

Objective-C 不支持泛型编程。 您始终可以使用 Objective-C++ 和 STL 列表。

Answer 3

通用 NSArray 可以通过子类化 NSArray 并用更严格的方法重新定义所有提供的方法来实现。 例如，

- (id)objectAtIndex:(NSUInteger)index

必须将

@interface NSStringArray : NSArray

重新定义为

- (NSString *)objectAtIndex:(NSUInteger)index

NSArray

仅包含 NSString。 创建的子类可以用作直接替换，并带来许多有用的功能：编译器警告、属性访问、更好的代码创建和 Xcode 中的完成。 所有这些都是编译时功能，无需重新定义实际实现 - NSArray 的方法仍然可以使用。

可以将其自动化并将其简化为仅两个语句，这使其接近支持泛型的语言。 我使用 WMGenericCollection 创建了一个自动化，其中模板作为 C 预处理器宏提供。

导入包含宏的头文件后，您可以创建一个带有两条语句的通用 NSArray：一条用于接口，一条用于实现。 您只需提供要存储的数据类型和子类的名称。 WMGenericCollection 为 NSArray、NSDictionary 和 NSSet 及其可变对应项提供此类模板。

Answer 4

不，Objective-C 目前不支持集合元素的参数类型。

然而，这个主题比问题或现有答案承认的更复杂。

Objective-C 中集合的参数类型与 C#/Java 中的泛型不同。 例如，您不太可能看到 Objective-C 添加了确保添加到集合中的每个对象都是 NSArray 类型或子类型的功能。 相反，Objective-C 可以（并且 IMO 应该）有能力确保集合中的每个对象都符合协议/接口。 （即它实现了一组必需的方法）

为什么？

Objective-C 是一种基于协议（接口）兼容性而不是子类型关系构建的语言。 也就是说，如果对象具有所有正确的方法，则它们是兼容的，我们不查看或关心它们的实际类型。 事实上，在 Obj-C 中查看实际类型是一种非常非常糟糕的做法，并且非常不鼓励。 这个概念有时被称为“鸭子打字”，因为如果它像鸭子一样嘎嘎叫，那么它就是鸭子。 我们不在乎它是否确实是从某些特定的鸭子继承的。 这可以防止您被其他人的实现层次结构所困扰。 -- 结果是，只要列表中出现的对象有一个可以工作的 draw:: 方法，我们实际上并不关心它是否是某个特定 JimmyDrawableBase 对象的子类。

这不仅使代码更可重用，而且还鼓励稍微不同（更实用？）类型的问题分解，因为您不能依赖从给定基类派生的对象，从而拥有一堆基类强制实施。

我个人认为 Obj-C 编译器对协议 *CONFORMANCE* 进行参数检查会很好。 也就是说，要创建一个 NSMutableArray，要求放置在其中的所有对象都符合给定的协议（即具有一组给定的所需方法）。

有时，甚至这种更灵活的协议一致性检查也会受到动态编程人员的抵制，并且有充分的理由。 程序员常常会过度指定一致性要求。

例如，您可能需要一个包含符合 NSArray 协议/接口的对象的列表，但您实际上可能只调用其中两个方法。 这是过度符合。 希望在数组中添加兼容项的人被迫实现大量您实际上并未调用的方法——至少现在还没有（请参见下文）。

Google Go 试图通过推断结构兼容性来解决这个问题。 也就是说，如果您对列表中的项目调用draw()，那么编译器会确保进入列表的所有内容都包含draw() 方法。 如果它不包含draw()方法，则将其放入列表中会出现编译器错误。 这可以防止代码在运行时简单地导致相同的错误发生。 这样做的问题是它只适用于整个程序编译。 如果 Google-Go 可以编译模块化 DLL（它不能），那么它就会遇到这样的问题：我没有办法说列表中的对象需要支持三种方法的特定接口，即使我今天不会给他们打电话，因为我将来可能会给他们打电话。

在这两种解决方案之间需要权衡和真相。

就我个人而言，我希望看到 Objective-C 添加参数协议一致性，因此我可以要求编译器确保特定集合的内容始终符合给定的协议集。

我还希望编译器帮助我避免过度一致性。 如果我没有在对象上调用这些协议中的方法，它应该生成错误/警告来告诉我这一点。 如果我想将它们保留在协议中，即使我没有使用它们，我应该必须为协议中的每个方法显式声明它“将来可能会使用，因此所有元素现在都需要提供它” ”。 这至少使得过度一致性的过程需要更多的工作，而不是 Java/C# 需要更少的工作。