第8条:理解“对象等同性”这一概念
本条要点：（作者总结）
- 若想检测对象的等同性，请提供 “isEqual:” 与 hash 方法。
- 相同的对象必须具有相同的哈希码，但是这两个哈希码相同的对象却未必相同。
- 不要盲目地逐个检测每条属性，而是应该依照具体需求来制定检测方案。
- 编写 hash 方法时，应该使用计算速度快而且哈希码碰撞几率低的算法。
i 根据“等同性”（equality）来比较对象是一个非常有用的功能。不过，按照 ＝＝ 操作符比较出来的结果未必是我们想要的，因为该操作比较的是两个指针本身，而不是其所指的对象。应该使用 NSObject 协议中声明的 “isEqual”: 方法来判断两个对象的等同性。一般来说，两个类型不同的对象总是不相等的（unequal）。某些对象提供了特殊的 “等同性判定方法”（equality-checking method），如果已经知道两个受测对象都属于同一个类，那么就可以使用这种方法。以下述代码为例:
1 NSString *foo = @"Badger 123"; 2 NSString *bar = [NSString stringWithFormat:@"Badger %i", 123]; 3 BOOL equalA = (foo == bar); // equalA = NO 4 BOOL equalB = [foo isEqual:bar]; // equalB = YES 5 BOOL equalC = [foo isEqualToString:bar]; // equalC = YES
大家可以看到 ＝＝ 与等同性判断方法之间的差别。 NSString 类实现了一个自己独有的等同性判断方法，名叫 “isEqualToString:”。传递给该方法的对象必须是 NSString ，否则结果未定义（undefined）。调用该方法比调用 “isEqual:”方法快，后者还要执行额外的步骤，因为它不知道受测对象的类型。
NSObject 协议中有两个用于判断灯头性的关键方法。
1 - (BOOL)isEqual:(id)object; 2 @property (readonly) NSUInteger hash; 3 4 + (NSUInteger)hash;
NSObject 类对这两个方法的默认实现是:当且仅当其“指针值”（point value）(可理解为内存地址) 完全相等时，这两个对象才相等。若想在自定义的对象中正确覆写这些方法，就必须先理解其约定（contract）。如果 “isEqual:”方法判定两个相等相等，那么其hash 方法也必须返回同一个值，但是，如果两个对象的 hash 方法返回同一值，，那么 “isEqual:”方法未必会认为两者相等。
比如有下面这个类:
1 @interface EOCPerson : NSObject 2 3 @property (nonatomic, copy) NSString *firstName; 4 @property (nonatomic, copy) NSString *lastName; 5 @property (nonatomic, assign) NSUInteger age; 6 7 @end
我们认为，如果两个 EOCPerson 的所有字段均相等，那么这两个对象就相等。于是 “isEqual:”方法可以完成：
1 - (BOOL)isEqual:(id)object { 2 if (self == object) { 3 return YES; 4 } 5 if ([self class] != [object class]) { 6 return NO; 7 } 8 EOCPerson *otherPerson = (EOCPerson *)object; 9 if (![_firstName isEqualToString:otherPerson.firstName]) { 10 return NO; 11 } 12 if (![_lastName isEqualToString:otherPerson.lastName]) { 13 return NO; 14 } 15 if (_age != otherPerson.age) { 16 return NO; 17 } 18 return YES; 19 }
首先，直接判断两个指针是否相等。若相等，则其均指向一个对象，所以受测的对象也必定相等。接下来，比较两个对象所属的类，若不属于同一个类，则两个对象不相等。 EOCPerson 对象当然不可能与 EOCDog 对象相等。不过，有时我们可能认为：一个 EOCPerson 实例可以与其子类（比如 EOCSmithPerson）实例相等。在继承体系（inheritance hierarchy）中判断等同性时，经常遭遇此问题。所以实现 “isEqual:” 方法时要考虑到这种情况。最后，检测每个属性是否相等。只要其中有不相等的属性，就判定两对象不等，否则两对象相等。
接下来该实现 hash 方法了。回想一下，根据等同性约定：若两对象相等，则其哈希码（hash）（“hash”一词也叫做“杂凑”、“散列”）也相等，但是两个哈希码相同的对象却未必相等。这是能否正确覆写 “isEqual:” 方法的关键所在。下面这种写法完全可行:
1 - (NSUInteger)hash { 2 return 1337; 3 }
不过若是这么写的话，在 collection 中使用这种对象将产生性能问题，因为 collection 在检索哈希表（hash table）时，会用对象的哈希码做索引。假如某个 collection 是用 set （“collection”与“set”在中文里都叫做“集合”，前者是Array、Dictionary、Set 等数据结构的总称。译文为避免混淆，保留这两个词的英文写法）实现的，那么 set 可能会根据哈希码把对象分装到不同的数组中（这种数组在后文中也称为 “箱子”(bind)）。在向 set 中添加新对象时，要根据其哈希码找到与之相关的数组，依次检查其中各个元素，看数组中已有的对象是否和将要添加的新对象相等。如果相等，那就说明要添加的对象已经在 set 里面了。由此可知，如果令每个对象都返回相同的哈希码，那么在 set 中已有 1 000 000 个对象的情况下，若是继续向其中添加对象，则需要将这 1 000 000 个对象全部扫描一遍。
hash 方法也可以这样来实现:
1 - (NSUInteger)hash { 2 NSString *stringToHash = [NSString stringWithFormat:@"%@:%@:%lu", _firstName, _lastName, (unsigned long)_age]; 3 return [stringToHash hash]; 4 }
这次所用的办法是将 NSString 对象中的属性都塞入另一个字符串中，然后令 hash 方法返回该字符串的哈希码。这么做符合约定，因为两个相等的 EOCPerson 对象总会返回相同的哈希码。但是这样做还需要负担创建字符串的开销，所以比返回单一值要慢。把这中对象添加到collection 中时，也会产生性能问题，因为要想添加，必须先计算其哈希码。
再来看最后一种计算哈希码的办法:
1 - (NSUInteger)hash { 2 NSUInteger firstNameHash = [_firstName hash]; 3 NSUInteger lastNameHash = [_lastName hash]; 4 NSUInteger ageHash = _age; 5 return firstNameHash ^ lastNameHash ^ ageHash; 6 }
这种做法既能保持较高效率，又能使生成的哈希码至少位于一定范围之内，而不会过于频繁的重复。当然，此算法生成的哈希码还是会碰撞（collection），不过至少可以保证哈希码有多种可能的取值。编写 hash 方法时，应该用当前的对象做做实验，以便减少碰撞频度与降低运算复杂程度之间取舍。
特定类所具有的等同性判定方法
除了刚才提到的 NSString 之外， NSArray 与 DSDictionary 类也具有特殊的等同性判定方法，前者名为“isEqualToArray:”，后者名为“isEqualToDictionary:”。如果和其比较的对象不是数组或字典，那么这两个方法会各自抛出异常。由于 Objective-C 在编译期不做强类型检查（strong type checking），这样容易不小心传入类型错误的对象，因此开发者应该保证所传对象的类型是正确的。
如果经常需要判断等同性，那么可能会自己来创建等同性判定方法，因为无须检测参数类型，所以能大大提升检测速度。自己来编写判定方法的另一个原因是，我们想令代码看上去更美观、更易读，此动机与 NSString 类 “isEqualToString:”方法的创建缘由相似，纯粹为了装点门面。使用此种判定方法编出来的代码更容易读懂，而且不用再检查两个受测对象的类型了。
在编写判定方法时，也应一并覆写“isEqual:”方法。后者的常见实现方式为:如果受测的参数与接收该消息的对象都属于同一类，那么久调用自己编写的判定方法，否则就交由超类来判断。例如，在 EOCPerson 类中可以实现如下两个方法:
1 - (BOOL)isEqualToPerson:(EOCPerson *)otherPerson { 2 if (self == otherPerson) { 3 return YES; 4 } 5 if (![_firstName isEqualToString:otherPerson.firstName]) { 6 return NO; 7 } 8 if (![_lastName isEqualToString:otherPerson.lastName]) { 9 return NO; 10 } 11 if (_age != otherPerson.age) { 12 return NO; 13 } 14 return YES; 15 } 16 17 - (BOOL)isEqual:(id)object { 18 if ([self class] == [object class]) { 19 return [self isEqualToPerson:(EOCPerson *)object]; 20 } else { 21 return [super isEqual:object]; 22 } 23 }
等同性判定的执行深度
创建等同性判定方法时，需要决定是根据整个对象来判断等同性，还是仅根据其中几个字段来判断。NSArray 的检测方式为先看两个数组所含对象个数是否相同，若相同，则在每个对应位置的两个对象身上调用其 “isEqual:” 方法。如果对应位置上的对象均相等，那么这两个数组就相等，这叫做“深度等同性判定”(deep equality)。不过有时候无须将所有数据逐个比较，只根据其中部分数据即可判明二者是否等同。
比如说，我们假设 EOCPerson 类的实例是根据数据库里的数据创建而来，那么其中就可能会含有另外一个属性，此属性是 “唯一标识符”（unique identifier），在数据库中用作 “主键”（primary key）:
1 @property NSUInteger identifier;
在这种情况下，我们也许只会根据标识符来判断等同性，尤其是在此属性声明为 readonly 时更应该如此。因为只要两者标识符相同，就肯定表示同一个对象，因而必然相等。这样的话，无须逐个比较 EOCPerson 对象的每条数据，只要标识符相同，就说明这两个对象就是同一个数据源所创建的，据此我们能够判定，其余数据也必然相同。
是否需要在等同性判定方法中检测全部字段取决于受测对象。只有类的编写者才可以确定两个对象实例在何种情况下应判定为相等。
容器中可变类的等同性
还有一种情况一定要注意，就是在容器中放入可变类对象的时候。把某个对象放入 collection 之后，就不应该再改变其哈希码了。前面解释过，collection 会把各个对象按照其哈希码分装到不同的 “箱子数组”中。如果某对象在放入“箱子”之后哈希码又变了，那么其现在所处的这个箱子对它来说是“错误”的。要想解决这个问题，需要确保哈希码不是根据对象的 “可变部分”（mutable portion）计算出来的，或是保证放入 collection 之后就不再改变对象内容了。
用一个 NSMutableSet 与几个 NSMutableArray 对象测试一下，就能发现这个问题了。首先把一个数组加入 set 中：
1 NSMutableSet *set = [NSMutableSet new]; 2 3 NSMutableArray *arrayA = [@[@1, @2] mutableCopy]; 4 [set addObject:arrayA]; 5 NSLog(@"set = %@", set); 6 // output: set = {((1, 2))}
现在 set 里含有一个数组对象，数组中包含两个对象。再向 set 中加入一个数组，此数组与前一个数组所含有的对象相同，顺序也相同，于是，待加入的数组与 set 中已有的数组是相等的:
1 NSMutableArray *arrayB = [@[@1, @2] mutableCopy]; 2 [set addObject:arrayB]; 3 NSLog(@"set ＝ %@", set); 4 // output: set = {((1, 2))}
此时 set 里仍然只有一个对象：因为刚才要加入的那个数组对象和 set 中已有的数组对象相等，所以 set 并不会改变。这次我们来添加一个和 set 中已有对象不同的数组：
1 NSMutableArray *arrayC = [@[@1] mutableCopy]; 2 [set addObject:arrayC]; 3 NSLog(@"set = %@", set); 4 // output: set = {((1), (1,2))}
正如大家所料，由于 arrayC 与 set 里已有的对象不相等，所以现在 set 里面有两个数组了:其中一个是最早加入的，另一个是钢才新添加的。最后，我们改变 arrayC 的内容，令其和最早加入 set 的那个数组相等:
1 [arrayC addObject:@2]; 2 NSLog(@"set = %@", set); 3 // Output: set = {((1, 2), (1, 2))}
set 中居然可以包含两个彼此相等数组！根据 set 的语义是不允许出现这种情况，然而现在却无法保证这一点了，因为我们修改了 set 中已有的对象。若是拷贝此 set，那就更糟糕了:
1 NSSet *setB = [set copy]; 2 NSLog(@"setB = %@", setB); 3 // output: setB = {((1, 2))}
复制过来的 set 中又只剩一个对象了，此 set 看上去好像是由一个空 set 开始、通过逐个向其中添加新对象而创建出来的。这可能符合你的需求，也可能不符合。有的开发者也许想要忽略 set 中的错误，“照原样”（verbatim）复制一个新的出来，还有的开发者则会认为这样做挺合适的。这两种拷贝算法都说的通，于是进一步印证了钢才提到的那个问题：如果把某对象放入 set 之后又修改其内容，那么后面的行为将很难预料。
举这个例子是想提醒大家：把某对象放入collection 之后改变其内容将会造成何种后果。笔者并不是说绝对不能这么做，而是说如果真这么做，那就得注意其隐患，并用相应的代码处理可能发生的问题。
END
