[Note] Effective OC - Item 23~25

Chapter 4. Protocols and Categories

---

Item 23: Use Delegate and Data Source Protocols for Inter-object Communication

这一节讲了delegate的原理和使用场景。
大部分内容我都比较熟悉，常写常用，就不记笔记了。这里只记一下最后提到了一块用bitfield data type来定义delegate flag的内容。这个用法没有见过，可能确实也不是很常用，文中用的词是”is often overlooked”。
bitfield data type的声明：

struct data {
 unsigned int fieldA : 8;
 unsigned int fieldB : 4;
};

这里表示fieldA有8个字节存储空间，也就可以存储2^8个值。如果用来做delegate flag，用于表示类有没有相应这个代理方法，只有响应和没响应两个情况，所以1bit就够了。可以在interface里这样写：

@interface EOCNetworkFetcher () {
struct {
     unsigned int didUpdateProgressTo : 1;
}_delegateFlags;
}
@end

在setter里赋值：

_delegateFlags.didUpdateProgressTo = [delegate respondsToSelector: @selector(networkFetcher:didUpdateProgressTo:)];

这样当需要检查代理是否有响应代理方法的时候，就不用调用respondsToSelector方法，而是直接检查flag就好了：

if (_delegateFlags: didUpdateProgressTo){
    //
}

这样做的好处是判断速度快，效率高。需要做这样优化的场景是需要多次调用代理方法的时候。因为每一次调用，为了安全都要先判断，如果不停地重复判断，就会比较低效，这时就可以考虑用这种flag判断来代替。

---

Item 24: Use Categories to Break Class Implementations into Manageable Segments

这一节讲的是通过给类创建category来让代码的功能分区更清晰。
在说category之前，我想先考虑一下category和inheritance怎么选择的问题。一般来说，这两个看上去最主要的区别是subclass可以添加新的属性。但是在前面的一节也提到了，可以用associated objects为category添加属性，所以根据这一区别来判断似乎也不是特别准确。我想应该还是从OO的本身意义出发来想，inheritance并不是单纯的“扩展”，而是创建了一个新类。这个新类应该有它存在的意义。而category是真正意义上的扩展，是针对原本的类增加功能，这些功能就是需要这个类来拥有的，而不是它的某个子集来拥有。
一个类的implementation里写了太多方法的话，大多数人的习惯还是用#pragma mark -来进行分区。这一节提出，用category来按功能分区效果更好，而且如果没必要把分类新建文件的话，大家仍可以都放在一个文件里，利用分类名来说明每一块的功能。
这样做的话，第一是代码逻辑和功能更加清晰了，更加self-documenting。第二是在调试的时候在调用的方法后面可以看到属于哪个分类，易于调试定位。
特别地，对于不暴露给外界的方法，可以考虑创建private category。

---

Item 25: Always Prefix Category Names on Third-Party Classes

这一节很短，说的是要给分类的分类名和分类中的方法名加上前缀。
所有需要加前缀的东西，本质原因都是为了避免冲突。放在分类这很好理解。因为分类的方法和类本来就有的方法是没有优先级之分的，都会出现在类的方法列表里。如果同一个方法定义实现了多次，运行时就不会知道执行的是其中哪个，导致很奇怪又很难发现的bug。
特别是当引入了第三方的类，不太清楚其内部实现的情况下，这样的危险就更大。
所以需要把分类名和分类中的方法名都加上前缀，人为建立name space，来避免命名冲突造成的方法相互覆盖。