[Note] Effective OC - Item 26~28

Chapter 4. Protocols and Categories

---

Item 26: Avoid Properties in Categories

这一节又说到分类里声明属性的问题了。
虽然在前面Item 10里讲了怎样利用associated object在分类里添加iVar并合成property的做法，但是当时也说到了，不是特殊的场景不建议这么做。这一节写了如果直接在分类里添加属性会发生什么。
分类自己是无法合成属性的iVar的，只能通过Item 10中提到的方法来做。属性的getter和setter方法也需要自己实现，或者声明为@dynamic，告诉编译器在runtime再实现。但是因为之前也提到过，associated object是绕过了memory-management semantics和KVO的，这样做会引起一些潜在的内存问题。
所以最稳妥的作法还是把跟这个类相关的属性都声明在main interface里。
这一节最后给了一个只读property然后自己实现了getter的例子，用来获取月份名称列表。因为在此例中并不需要iVar，所以是可以的，并且编译器也不会抱怨，因为所需方法都自己实现了，编译器就认为不用合成iVar了（对这个坑我也是踩了好几次…）。但是这样做和直接写一个获取名称列表的方法效果上也没什么不同，会有点舍近求远的感觉。

---

Item 27: Use the Class-Continuation Category to Hide Implementation Detail

Class-continuation category这个说法在别处好像大都不这么叫，其实就是class extension。这一节讲的是可以在class extension里定义什么，这样做的好处是什么。
class extension真的是一直在用，非常熟悉。它也是分类的一种，而且是唯一一种可以合成iVar的分类。
一般在它里面定义的是只有类的内部实现才会用到的iVar和属性。虽然在.h中把属性定义为private理论上也是把属性设置为私有了，但是有各种方法可以修改这种定义，比如我们常用的KVC。而定义在class extension里就私有化多了，虽然仍然有方法可以修改，但是还是安全多了。
当然iVar也可以直接声明在implementation里，但是不如写在class extension中清晰。都写在class extension里以后，类所私有的数据就一目了然。包括类所遵守的协议，如果不想让外界知道，或者跟外界没有关系的，都应该放在class extension。
还有一个常用的用法是，在.h中声明的readonly属性，在class extension中重新声明为readwrite，然后就可以在类内部方便地修改了，而外界原则上还是只能只读这个属性。这个用法在前面也提到过。

---

Item 28: Use a Protocol to Provide Anonymous Objects

这一节讲的是id这种形式的匿名对象。
这个概念是说，因为这里id可以表示任何类，所以这个对象属于什么类这一信息是未知的，即“anonymous”，所能知道的关于这个对象的唯一信息就是它遵守了某个协议，也就是只知道它实现了某几个方法。
这样写的原因一般由两个，一个是想表达“在此处类型不重要”，一个是表示“在此处并不想告诉外界真正的类是什么”。
在自定义协议的时候，第一个用法很常见。一般为一个类写完一个协议，然后会在这个类里加一个delegate属性，这个属性的类型就是id，这里表达的意思是并不在意究竟是谁来做这个代理，只要能实现协议里的方法就可以。
另一个场景就是文中提到的，主观上不想让外界知道这个对象类型的时候。文中的例子是处理数据库连接的一个API，其中有方法：

- (id)connectionWithIdentifier:(NSString *)identifier;

这里返回类型是刻意被隐藏的。因为处理连接的类是多种多样的，可以不是继承自同一基类的，内部的实现可以根据情况自由选择，但是并不想让外界知道这些细节，所以只告诉外界一个id类型，并提供一个的协议信息，告诉外界不管使用什么类实现的，这个类都可以用来做连接、断开、查询数据库等操作。而这个信息对外界来说已经足够了，完全不影响对类的正常使用。而对内的安全性和私有性又得到了保障。