第二章 对象、消息、运行期—第8条:理解"对象等同性"这一概念

根据"等同性"(equality)来比较对象是一个非常有用的功能。不过，按照==操作符比较出来的结果未必是我们想要的，因为该操作比较的是两个指针本身，而不是其所指的对象。应该使用NSObject协议中声明的"isEqual":方法来判断两个对象的等同性。一般来说，两个类型不同的对象总是不相等的(unequal)。某些对象提供了特殊的"等同性判定方法"(equality-checking method)，如果已经知道两个受测对象都属于同一个类，那么就可以使用这种方法。以下述代码为例:

NSString *foo = @"Badger 123";
NSString *bar = [NSString stringWithFormat:@"Badger %i", 123];
BOOL equalA = (foo == bar);//

可以看到==与等同性判断方法之间的差别。NSString类实现了一个自己独有的等同性判断方法，名叫"isEqualToString:"。传递给该方法的对象必须是NSString，否则结果未定义(undefined)。调用该方法比调用"isEqual:"方法快，后者还要执行额外的步骤，因为它不知道受测对象的类型。
NSObject协议中有两个用于判断等同性的关键方法:

- (BOOL)isEqual:(id)object;
- (NSUInteger)hash;

NSObject类对这两个方法的默认实现是:当且仅当其"指针值"(pointer value)完全相等时，这两个对象才相等。若想在自定义的对象中正确覆写这些方法，就必须先理解其约定(contract)。如果"isEqual:"方法判定两个对象相等，那么其hash方法也必须返回同一个值。但是，如果两个对象的hash方法返回同一个值，那么"isEqual:"方法未必会认为两者相等。
比如有下面这个类:

@interface EOCPerson : NSObject
@property (nonatomic, copy) NSString *firstName;
@property (nonatomic, copy) NSString *lastName;
@property (nonatomic, assign) NSUInteger age;
@end

我们认为，如果两个EOCPerson的所有字段均相等，那么这两个对象就相等。于是，"isEqual:"方法可以写成:

- (BOOL)isEqual:(id)object {
      if (self == object) return YES;
      if ([self class] != [object class]) return NO;

      EOCPerson *otherPerson = (EOCPerson *)object;
      if (![_firstName isEqualToString: otherPerson.firstName])
            return NO;
      if (![_lastName isEqualToString: otherPerson.lastName])
            return NO;
      if (_age != otherPerson.age)
            return NO;
      return YES;
}

首先，直接判断两个指针是否相等。若相等，则其均指向同一对象，所以受测的对象也必定相等。接下来，比较两对象所属的类。若不属于同一个类，则两对象不相等。EOCPerson对象当然不可能与EOCDog对象相等。不过，有时我们可能认为:一个EOCPerson实例可以与其子类(比如EOCSmithPerson)实例相等。在继承体系(inheritance hierarchy)中判断等同性时，经常遭遇此类问题。所以实现"isEqual:"方法要考虑到这种情况。最后，检测每个属性是否相等。只要其中有不相等的属性，就判定两对象不等，否则两对象相等。
接下来该实现hash方法了。回想一下，根据等同性约定:若两对象相等，则其哈希码(hash)也相等，但是两个哈希码相同的对象却未必相等。这是能否正确覆写"isEqual:"方法的关键所在。下面这种写法完全可行:

- (NSUInteger)hash
{
    return 1337;
}

不过若是这么写的话，在collection中使用这种对象将产生性能问题，因为collection在检索哈希表(hash table)时，会用对象的哈希码做索引。假如某个collection是用set实现的，那么set可能会根据哈希码把对象分装到不同的数组中。在向set中添加新对象时，要根据其哈希码找到与之相关的那个数组，依次检查其中各个元素，看数组中已有的对象是否和将要添加的新对象相等。如果相等，那就说明要添加的对象已经在set里面了。由此可知，如果令每个对象都返回相同的哈希码，那么在set中已有1000000个对象的情况下，若是继续向其中添加对象，则需将这1000000个对象全部扫描一遍。
hash方法也可以这样来实现:

- (NSUInteger)hash
{
      NSString *stringToHash = [NSString stringWithFormat:@"%@: %@: %i", _firstName, _lastName, _age];
      return [stringToHash hash];
}

这次所用的办法是将NSString对象中的属性都塞入另一个字符串中，然后令hash方法返回该字符串的哈希码。这么做符合约定，因为两个相等的EOCPerson对象总会返回相同的哈希码。但是这样做还需负担创建字符串的开销，所以比返回单一值要慢。把这种对象添加到collection中时，也会产生性能问题，因为要想添加，必须先计算其哈希值。
再来看最后一种计算哈希码的办法:

- (NSUInteger)hash
{
      NSUInteger firstNameHash = [_firstName hash];
      NSUInteger lastNameHash = [_lastName hash];
      NSUInteger ageHash = [_age hash]; 
      return firstNameHash ^ lastNameHash ^ ageHash;
}

这种做法既能保持较高效率，又能使生成的哈希码至少位于一定范围之内，而不会过于频繁地重复。当然，此算法生成的哈希码还是会碰撞(collision)，不过至少可以保证哈希码有多种可能的取值。编写hash方法时，应该用当前的对象做做实验，以便在减少碰撞频度与降低运算复杂程度之间取舍。

特定类所具有的等同性判定方法
除了刚才提到的NSString之外，NSArray与NSDictionary类也具有特殊的等同性判定方法，前者名为"isEqualToArray:"，后者名为"isEqualToDictionary:"。如果和其相比较的对象不是数组或字典，那么这两个方法会各自抛出异常。由于Objective-C在编译期不做强制类型检查(strong type checking)，这样容易不小心传入类型错误的对象，因此开发者应该保证所传对象的类型是正确的。
如果经常需要判断等同性，那么可能会自己来创建等同性判定方法，因为无须检测参数类型，所以能大大提升检测速度。自己来编写判定方法的另一个原因是，我们想令代码看上去更美观、更易读，此动机与NSString类"isEqualToString:"方法的创建缘由相似，纯粹为了装点门面。使用此种判定方法编出来的代码更容易读懂，而且不用再检查两个受测对象的类型了。
在编写判定方法时，也应一并覆写"isEqual:"方法。后者的常见实现方式为:如果受测的参数与接收该消息的对象都属于同一个类，那么就调用自己编写的判定方法，否则就交由超类来判断。例如，在EOCPerson类中可以实现如下两个方法:

- (BOOL)isEqualToPerson:(EOCPerson *)otherPerson {
        if (self == object) return YES;
        if (![_first isEqualToString:otherPerson.firstName]) 
                return NO;
        if (![_lastName isEqualToString:otherPerson.lastName]) 
                return NO;
        if (![_age != otherPerson.age]) 
                return NO;
        return YES;
}

- (BOOL)isEqual:(id)object {
      if ([self class] == [object class]) {
            return [self isEqualToPerson:(EOCPerson *)object];
      }else {
          return [super isEqual:object];
      }
}

等同性判定的执行深度
创建等同性判定方法时，需要决定是根据整个对象来判断等同性，还是仅根据其中几个字段来判断。NSArray的检测方式为先看两个数组所含对象个数是否相同，若相同，则在每个对应位置的两个对象身上调用其"isEqual:"方法。如果对应位置上的对象均相等，那么这两个数组就相等，这叫做"深度等同性判定"(deep equality)。不过有时候无须将所有数据逐个比较，只根据其中部分数据即可判明二者是否等同。
比方说，我们假设EOCPerson类的实例是根据数据库里的数据创建而来，那么其中就可能会含有另外一个属性，此属性是"唯一标识符"(unique identifier)，在数据库中用作"主键"(primary key):

@property NSUInteger identifier;

在这种情况下，我们也许只会根据标识符来判断等同性，尤其是在此属性声明为readonly时更应该如此。因为只要两者标识符相同，就肯定表示同一个对象，因而必然相等。这样的话，无须逐个比较EOCPerson对象的每条数据，只要标识符相同，就说明这两个对象就是由同一个数据源所创建的，据此我们能够判定，其余数据也必然相同。
是否需要在等同性判定方法中检测全部字段取决于受测对象。只有类的编写者才可以确定两个对象实例在何种情况下应判定为相等。

容器中可变类的的等同性
还有一种情况一定要注意，就是在容器中放入可变类对象的时候。把某个对象放入collection之后，就不应再改变其哈希码了。前面解释过，collection会把各个对象按照其哈希码分装到不同的"箱子数组"中。如果某对象在放入"箱子"之后哈希码又变了，那么其现在所处的这个箱子对它来说就是"错误"的。要想解决这个问题，需要确保哈希码不是根据对象的"可变部分"(mutable portion)计算出来的，或是保证放入collection之后就不再改变对象内容了。笔者将在第18条中解释为何要将对象做成"不可变的"(immutable)。这里先举个例子，此例能很好地说明其中缘由。
用一个NSMutableSet与几个NSMutableArray对象测试一下，就能发现这个问题了。首先把一个数组加入set中:

NSMutableSet *set = [NSMutableSet new];

NSMutableArray *arrayA = [@[@1, @2] mutableCopy];
[set addObject:arrayA];
NSLog(@"set = %@", set);
//Output : set = {((1, 2))}

现在set里含有一个数组对象，数组中包含两个对象。再向set中加入一个数组，此数组与前一个数组所含的对象相同，顺序也相同，于是，待加入的数组与set中已有的数组是相等的:

NSMutableArray *arrayB = [@[@1, @2] mutableCopy];
[set addObject:arrayB];
NSLog(@"set = %@", set);
//Output : set = {((1, 2))}

此时set里仍然只有一个对象:因为刚才要加入的那个数组对象和set中已有的数组对象相等，所以set并不会改变。这次我们来添加一个和set中已有对象不同的数组:

NSMutableArray *arrayC = [@[@1] mutableCopy];
[set addObject:arrayC];
NSLog(@"set = %@", set);
//Output: set = {((1), (1, 2))}

正如大家所料，由于arrayC与set里已有的对象不相等，所以现在set里有两个数组了:其中一个是最早加入的，另一个是刚才新添加的。最后，我们改变arrayC的内容，令其和最早加入set的那个数组相等:

[arrayC addObject:@2];
NSLog(@"set = %@", set);
//Output : set = {((1, 2), (1, 2))}

set中居然可以包含两个彼此相等的数组！根据set的语义是不允许出现这种情况的，然而现在却无法保证这一点了，因为我们修改了set中已有的对象。若是拷贝此set，那就更糟糕了:

NSSet *setB = [set copy];
NSLog(@"setB = %@", setB);
//Output: setB = {((1, 2))}

复制过来的set又只剩一个对象了，此set看上去好像是由一个空set开始、通过逐个向其中添加新对象而创建出来的。这可能符合你的需求，也可能不符合。有的开发者也许想要忽略set中的错误，"照原样"(verbatim)复制一个新的出来，还有的开发者则会认为这样做挺合适的。这两种拷贝算法都说的通，于是就进一步印证了刚才提到的那个问题:如果把某对象放入set之后又修改其内容，那么后面的行为将很难预料。
举这个例子是想提醒大家:把某对象放入collection之后改变其内容将会造成何种后果。笔者并不是说绝对不能这么做，而是说如果真要这么做，那就得注意其隐患，并用相应的代码处理可能发生的问题。