在Objective-C中如何正确地覆盖isEqual: ?“陷阱”似乎是，如果两个对象相等(由isEqual:方法决定)，它们必须具有相同的散列值。
Cocoa Fundamentals Guide的Introspection部分确实有一个关于如何重写isEqual:的例子，复制如下，用于一个名为MyWidget的类:
- (BOOL)isEqual:(id)other {
if (other == self)
return YES;
if (!other || ![other isKindOfClass:[self class]])
return NO;
return [self isEqualToWidget:other];
}
- (BOOL)isEqualToWidget:(MyWidget *)aWidget {
if (self == aWidget)
return YES;
if (![(id)[self name] isEqual:[aWidget name]])
return NO;
if (![[self data] isEqualToData:[aWidget data]])
return NO;
return YES;
}
它检查指针是否相等，然后是类是否相等，最后使用isEqualToWidget:比较对象，后者只检查名称和数据属性。这个例子没有说明如何重写哈希。
让我们假设有其他属性不影响平等，比如年龄。难道不应该重写哈希方法，以便只有名称和数据影响哈希吗?如果是，你会怎么做?只是添加名称和数据的散列吗?例如:
- (NSUInteger)hash {
NSUInteger hash = 0;
hash += [[self name] hash];
hash += [[self data] hash];
return hash;
}
这足够了吗?有更好的技术吗?如果你有基本类型，比如int呢?将它们转换为NSNumber以获得它们的散列?或者像NSRect这样的结构?
(脑屁:最初把“位或”和|=写在一起。意味着添加。)
我发现这个线程非常有帮助，提供了我需要的一切来获得我的isEqual:和哈希方法实现了一个捕获。当测试isEqual中的对象实例变量时:示例代码使用:
if (![(id)[self name] isEqual:[aWidget name]])
return NO;
当我知道在我的单元测试中对象是相同的时，这个反复失败(即返回NO)而没有和错误。原因是，其中一个NSString实例变量是nil，所以上面的语句是:
if (![nil isEqual: nil])
return NO;
因为nil会响应任何方法，这是完全合法的，但是
[nil isEqual: nil]
返回nil，这是NO，所以当对象和被测试的对象都有一个nil对象时，它们将被认为是不相等的(即，isEqual:将返回NO)。
这个简单的修复是将if语句更改为:
if ([self name] != [aWidget name] && ![(id)[self name] isEqual:[aWidget name]])
return NO;
这样，如果它们的地址是相同的，无论它们都是nil或都指向同一个对象，它都会跳过方法调用，但如果其中一个不是nil或它们指向不同的对象，则会适当地调用比较器。
我希望这能让一些人少挠头几分钟。
请注意，如果创建的对象在创建后可以更改，则如果该对象插入到集合中，则哈希值不能更改。实际上，这意味着哈希值必须从初始对象创建时开始固定。更多信息请参阅Apple的NSObject协议的-hash方法文档:
If a mutable object is added to a collection that uses hash values to determine the object’s position in the collection, the value returned by the hash method of the object must not change while the object is in the collection. Therefore, either the hash method must not rely on any of the object’s internal state information or you must make sure the object’s internal state information does not change while the object is in the collection. Thus, for example, a mutable dictionary can be put in a hash table but you must not change it while it is in there. (Note that it can be difficult to know whether or not a given object is in a collection.)
对我来说，这听起来完全是无稽之谈，因为它可能会有效地降低哈希查找的效率，但我认为最好还是谨慎行事，并遵循文档所说的。
Quinn错误地认为对杂音散列的引用在这里是无用的。Quinn说得对，你想要理解哈希背后的理论。低语将很多理论提炼成一个实现。弄清楚如何将该实现应用到这个特定的应用程序是值得研究的。
这里有一些关键点:
tcurdt的示例函数表明，'31'是一个很好的乘数，因为它是质数。我们需要证明质数是充要条件。事实上，31(和7)可能不是特别好的质数，因为31 == -1 % 32。一个奇数的乘数，大约有一半的位被设置，一半的位被清除，可能会更好。(杂音哈希乘法常量具有该属性。)
如果在相乘之后，通过shift和xor调整结果值，这种类型的哈希函数可能会更强。乘法倾向于在寄存器的高端产生大量位交互的结果，而在寄存器的低端产生低交互的结果。shift和xor增加了寄存器底部的交互作用。
将初始结果设置为一个值，其中大约一半的位为0，大约一半的位为1，也会很有用。
注意元素组合的顺序可能是有用的。首先应该处理布尔值和其他值不是强分布的元素。
在计算的最后添加几个额外的位置乱阶段可能是有用的。
对于这个应用程序，杂音散列是否真的快是一个悬而未决的问题。杂音散列预混每个输入字的位。多个输入字可以并行处理，这有助于多问题流水线cpu。
