Chapter 2. Objects, Messaging, and the Runtime
<br />
Item 7: Access Instance Variable Primarily Directly When Accessing Them Internally
<br />
这一篇讲解关于ivar的访问，什么时候应采取直接访问，什么时候应采取属性访问。
前一篇提到过，外部访问某个类的ivar，只能通过属性。而类的内部有直接访问和通过属性访问两种方式。
对于这个问题，我在文档中见到过，是这样说的：
尽量总是使用点操作符访问属性，而不是属性生成的 iVar 变量。以下情形除外：
- 明确要避免修改产生 KVO 通知的；
- 需重写属性 getter 或 setter 的；
- 性能分析确定使用属性会导致性能不可接受的；
- 多线程环境中，为防止互斥一次进行多个修改的；
- init、dealloc 方法中。
除了第四条，其他四点文中都多少提到了。从这些例外中可以看出这两种方法的区别。区别的根源就在于属性访问的本质是调用方法，而直接访问是直接读取变量所在内存。由于本质实现的不同，造成了两者各有优缺点：
- 属性访问：会经过method dispatch。会触发KVO通知。可以在方法里监控赋值和获取过程。方法在继承体系中可能会被override。setter方法保证内存管理语义。
- 直接访问：速度快。不经过setter，也就不在意属性里标注的内存管理语义。不会触发KVO通知。
文中建议：
写入ivar时，做属性访问，以保证内存管理语义得以贯彻。读取时，直接读取，保证速度。
还有特意提到了init方法中的写法。举得例子稍微有点绕。解释起来是这样的，init方法中推荐采取直接访问，原因是属性访问是方法调用，而方法调用有它的继承系统。调用setter的时候可能调用的不是本类而是子类的setter，引起一些意想不到的问题。除非是在无法直接访问的情况下，比如父类的私有ivar，这时子类其实已经属于“外界”范畴了，只能通过属性来访问。
另外还提到了对属性进行lazy initialization后必须采取属性访问才能使ivar得到初始化，也很好理解，因为不采用属性访问也就没有调用getter，ivar的内存空间当然是空的。这一点我在帮别人调bug时遇到过，还是比较容易发现，调试时发现属性为空的话应该考虑查一下这里。
<br />
Item 8: Understand Object Equality
<br />
这一篇讨论怎样判断两个对象相等的问题。
这里是专门针对对象来说的。因为scalar type判断相等很容易，用==就可以做到。判断对象相等稍微麻烦一点，原因在于它的引用是一个指针，指针指向的才是真正的对象。
系统为一些基本类提供了自己特有的判断相等的方法。比如isEqualToString:, isEqualToArray:, isEqualToDictionary: 等。如果是对这样的类进行判断，推荐直接用这些方法，优点是比通用的方法更省时，代码也更清晰。需要注意的只有一点，传入的对象必须是相应的数据类型。
对于一般的NSObject，判断相等涉及到两个方法：
- (BOOL)isEqual:(id)object;
- (NSUInteger)hash;
两个方法结果的关系是这样的：isEqual: => hash。是一个单推的关系。非常好理解，因为hash这个映射本来就是个单推的映射，无法反推的原因在于collision的存在。
isEqual的写法根据不同的类因地制宜。共同处是一开始判断一下两个对象的类是否一致，若不一致直接返回NO。或者如果仿照NSString那样为自定义类写了特有的判断相等方法，则结构应该是，若两个对象的类一致，则用类特有判等方法判定，否则调用父类的isEqual方法。这里不直接返回NO的原因是，有些情况可以认为父类的对象和子类的对象相等。（如果没有这个需求，我觉得是可以直接返回NO的。）
hash的写法也没有定规。原则和hash本身的原则类似，体现特定对象的特点，在不考虑资源的情况下尽量减少collision为佳。
文中提到了判等中两个较特殊的情况：
一个是Deep Equality vs. Shallow Equality。这种一般针对包含多个属性的类而言。顾名思义Deep Equality肯定是全方位比较了所有属性来判定相等。而Shallow Equality利用了Unique Identifier，只判断一个属性或者部分属性就可以判定相等，效率更高。
第二个是container with mutable objects的情况。这里的警示就是一旦放入container，可变对象就不要再变了，因为container不会对内部的元素再来判断相等与否，一旦修改可能会引起重复元素等混乱情况。
<br />
Item 9: User the Class Cluster Pattern to Hide Implementation Detail
<br />
这一篇讲的是Class Cluster。是一个其实经常接触到但是从来没有注意到的东西。大概这正是它”hide implementation detail”的初衷吧→_→
在Stephen Kochan《Programming in Objective C》中是这样说的：
An abstract class that groups a set of private concrete subclasses, providing a simplified interface to the user through the abstract class.
所以乍一看好像有点像java中的abstract class，其实差别还是挺大的。
这个定义还有这篇的标题都给出了这样做的motivation。系统的Foundation框架中很多基本类其实都是class cluster，比如NSString, NSArray, NSDictionary, NSNumber等。此外还有很多类，比如文中举的例子是UIButton。用buttonWithType:方法可以创造出不同子类的button，而创建String的时候也是同理的，但是用的时候并不能意识到，我在打印时见到NSCFString这个类一度不知道是哪来的。也就是说，class cluster通过一个各种子类通用的接口，调用同一个cluster的工厂方法创建不同子类的对象，从而把背后的子类细节隐藏了。
这样做的好处是编程的人不需要知道各种繁琐的子类名称，只要根据需求选type就可以了。或者都不用编程的人选，编译时根据环境需要默默帮你选好了。
需要注意的问题是，由于创建的对象在代码中显露的类名是class cluster的类名而不是真实的子类名，如果需要判断它的所属类，应调用isKindOfClass:方法，而不要直接判断所属类是不是和代码中显示的创建类相等。
文中还提出了向类组中增加新的子类的规则，这方面我没有实践经验_(:з」∠)_ 直接引用下原文的说法：
- 首先让子类继承自class cluster类。
- 子类需要定义自己的数据存储结构，因为class cluster类并没有定义。
- override文档中指定的方法。
