Effective Objective-C 2.0 读书笔记

《Effective Objective-C 2.0（编写高质量iOS与OS X代码的52个有效方法）》这本书已经买了有一段时间了，一直没有时间读完，趁着这个十一在家没事终于读过了，顺便做一下读书笔记总结记录一下吧。

第 1 章：熟悉Objective-C

第 1 条：了解Objective-C语言的起源

要点：
– Objective-C 为 C 语言添加了面向对象的特性，是其超集。Objective-C 使用动态绑定的消息结构，也就是说，在运行时才会去检查对象类型。接收一条消息之后，究竟应执行何种代码，由运行期环境而非编译器来决定。
– 理解 C 语言的核心概念有助于写好 Objective-C 程序。尤其要掌握内存模型与指针。

第 2 条：在类的头文件中尽量少引入其他头文件

要点：
– 除非确有必要，否则不要引入头文件。一般来说，应在某个类的头文件中使用向前声明来提及别的类，并在实现文件中引入那些类的头文件。这样做可以尽量降低类之间的耦合（coupling）。
– 有时无法使用向前声明，比如要声明某个类遵循一项协议。这种情况下，尽量把“该类遵循某协议”的这条声明移至“class-continuation分类”中。如果不行的话，就把协议单独放在一个头文件中，然后将其引入。

第 3 条：多用字面量语法，少用与之等价的方法

要点：
– 应该使用字面量语法来创建字符串、数值、数组、字典。与创建此类对象的常规方法相比，这么做更加简明扼要。
– 应该通过取下标操作在访问数组下标或字典中的键所对应的元素。
– 用字面量语法创建数组或字典时，若值中有 nil，则会抛出异常。因此，务必确保值里不含 nil。

第 4 条：多用类型常量，少用#define预处理指令

要点：
– 不要用预处理指令定义常量。这样定义出来的常量不含类型信息，编译器只是会在编译前据此执行查找与替换操作。即使有人重新定义了常量值，编译器也不会产生警告信息，这将导致应用程序中的常量值不一致。
– 在实现文件中使用 static const 来定义“只在编译单元内可见的常量”（translation-unit-specific constant）。由于此类常量不在全局符号表中，所以无须为其名称加前缀。
– 在头文件中使用 extern 来声明全局变量，并在相关实现文件中定义其值。这种常量要出现在全局符号表中，所以其名称应加以区隔，通常用与之相关的类名做前缀。

第 5 条：用枚举表示状态、选项、状态码

要点：
– 应该用枚举来表示状态机的状态、传递给方法的选项以及状态码等值，给这些值起个易懂的名字。
– 如果把传递给某个方法的选项表示为枚举类型，而多个选项又可同时使用，那么就将各选项值定义为2的幂，以便通过按位或操作将其组合起来。
– 用 NS_ENUM 与 NS_OPTIONS 宏来定义枚举类型，并指明其底层数据类型。这样做可以确保枚举是用开发者所选的底层数据类型实现出来的，而不会采用编译器所选的类型。
– 在处理枚举类型的 switch 语句中不要实现 default 分支。这样的话，加入新枚举之后，编译器就会提示开发者：switch 语句并未处理所有枚举。

第 2 章：对象、消息、运行期

第 6 条：理解“属性”这一概念

– ABI（Application Binary Interface）：应用程序二进制接口。
– 使用 @dynamic 关键字能阻止编译器自动合成存取方法，他会告诉编译器：不要自动创建实现属性所用的实例变量，也就不要为其创建存取方法。

要点：
– 可以用 @property 语法来定义对象中所封装的数据。
– 通过 “特质” 来指定存储数据所需的正确语义。
– 在设置属性所对应的实例变量时，一定要遵从该属性所声明的语义。
– 开发 iOS 程序时应该使用 nonatomic 属性，因为 atomic 属性会严重影响性能。

第 7 条：在对象内部尽量直接访问实例变量

要点：
– 在对象内部读取数据时，应该直接通过实例变量来读，而写入数据时，则应该通过属性来写。
– 在初始化方法及 dealloc 方法中，总是应该直接通过实例变量来读写数据。
– 有时会使用惰性初始化技术配置某份数据，在这种情况下，需要通过属性来读去数据。

第 8 条：理解“对象等同性”这一概念

要点：
– 若想检测对象的等同性，请提供“isEqual:”与 hash 方法。
– 相同的对象必须具有相同的哈希码，但是两个哈希码相同的对象却未必相同。
– 你要盲目地逐个检测每条属性，而是应该按照具体需求来制定检测方案。
– 编写 hash 方法时，应该使用计算速度快而且哈希码碰撞几率低的算法。

第 9 条：以“类族模式”隐藏实现细节

要点：
– 类族模式可以把实现细节隐藏在一套简单的公共接口后面。
– 系统框架中经常使用类族。
– 从类族的公共抽象基类中继承子类时要当心，若有开发文档，则应首先阅读。

第 10 条：在既有类中使用关联对象存放自定义数据

要点：
– 可以通过“关联对象”机制把两个对象连起来。
– 定义关联对象时可指定内存管理语义，用以模仿定义属性时所采用的“拥有关系”与“非拥有关系”。
– 只有在其他做法不可行时才应选用关联对象，因为这种做法通常会引入难于查找的 bug。

第 11 条：理解 objc_msgSend 的作用

要点：
– 消息由接受者、选择子及参数构成。给某对象“发送消息”（invoke a message）也就相当于在该对象上“调用方法”（call a method）。
– 发给某对象的全部消息都要由“动态消息派发系统”（dynamic message dispatch system）来处理，该系统会查出对应的方法，并执行其代码。

第 12 条：理解消息转发机制

要点：
– 若对象无法响应某个选择子，则进入消息转发流程。
– 通过运行期的动态方法解析功能，我们可以在需要用到某个方法时再将其加入类中。
– 对象可以把其无法解读的某些选择子转交给其他对象来做。
– 经过上述两步后，如果还是没办法处理选择子，那就启动完整的消息转发机制。

第 13 条：用“方法调配技术”调试“黑盒方法”

要点：
– 在运行期，可以向类中新增或替换选择子所对应的方法实现。
– 使用另一份实现来替换原有的方法实现，这道工序叫做“方法调配”，开发者常用此技术向原有实现中添加新功能。
– 一般来说，只有调试程序的时候才需要在运行期修改方法实现，这种做法不宜滥用。

第 14 条：理解“类对象”的用意

要点：
– 每个实例都有一个指向 Class 对象的指针，用以表明其类型，而这些 Class 对象则构成了类的集成体系。
– 如果对象类型无法在编译器确定，那么就应该使用类型信息查询方法来探知。
– 尽量使用类型信息查询方法来确定对象类型，而不要直接比较类对象，因为某些对象可能实现了消息转发功能。

第 3 章：接口与 API 设计

第 15 条：用前缀避免命名空间冲突

要点：
– 选择与你的公司、应用程序或二者皆有关联之名称作为类名的前缀，并在所有代码中均使用这一前缀。
– 若自己所开发的程序库中用到了第三方库，则应为其中的名称加上前缀。

第 16 条：提供“全能初始化方法”

要点：
– 在类中提供一个全能初始化方法，并于文档中指明。其他初始化方法均应调用此方法。
– 若全能初始化方法与超类不同，则需覆写超类中的对应方法。
– 如果类的初始化方法不适用于子类，那么应该覆写这个超类方法，并在其中抛出异常。

第 17 条：实现 description 方法

要点：
– 实现 description 方法返回一个有意义的字符串，用以描述实例。
– 若想在调试时候打印出更详尽的对象描述信息，则应实现 debugDescription 方法。

第 18 条：尽量使用不可变对象

要点：
– 尽量创建不可变的对象。
– 若某些属性仅可于对象内部修改，则在 “class-continuation 分类” 中将其有 readonly 属性扩展为 readwrite 属性。
– 不要把可变的 collection 作为属性公开，而应该提供相关的方法，以此修改对象中的可变 collection。

第 19 条：使用清晰而协调的命名方式

要点：
– 起名时应遵从标准的 Objective-C 命名规范，这样创建出来的接口更容易为开发者所理解。
– 方法名要言简意赅，从左到右读起来要像个日常用语中的句子才好。
– 方法名里不要使用缩略后的类型名称。
– 给方法起名时的第一要务就是确保其风格与你自己的代码或所要集成的框架相符。

第 20 条：为私有名称加前缀

要点：
– 给私有方法的名称加上前缀，这样就可以很容易的将其同公共方法区分开。
– 不要单用一个下划线做私有方法的前缀，因为这种做法是预留给苹果公司用的。

第 21 条：理解 Objective-C 错误类型

要点：
– 只有发生了可使整个应用程序崩溃的严重错误时，才应使用异常。
– 在错误不那么严重的情况下，可以指派“委托方法”（delegate method）来处理错误，也可以把错误信息放在 NSError 对象里，经由“输出参数”返回给调用者。

第 22 条：理解 NSCopying 协议

要点：
– 若想令自己所写的对象具有拷贝功能，则需要实现 NSCopying 协议。
– 如果自定义的对象分为可变版本与不可变版本，那么就要同时实现 NSCopying 与 NSMutableCopying 协议。
– 复制对象时需要决定采用浅拷贝还是深拷贝，一般情况下应该尽量执行浅拷贝。
– 如果你所写的对象需要深拷贝，那么可考虑新增一个专门执行深拷贝的方法。

第 4 章：协议与分类

第 23 条：通过委托与数据源协议进行对象间通信

@property (nonatomic, weak) id<EOCNetworkFetcherDelegate> delegate;，这个属性需定义成 weak，而非 strong，因为两者之间必须为“非拥有关系”（nonowning relationship）。
存放委托对象的这个属性要么定义成 weak，要么定义成 unsafe unretained，如果需要在相关对象销毁时自动清空（autoniling， 参见第 6 条），则定义为前者，若不需要自动清空，则定义为后者。

要点：
– 委托模式为对象提供了一套接口，使其可由此将相关事件告知其他对象。
– 将委托对象应该支持的接口定义成协议，在协议中把可能需要处理的事件定义成方法。
– 当某对象需要从另外一个对象中获取数据时，可以使用委托模式。在这种情境下，该模式亦称“数据源模式”（data source protocal）。
– 若有必要，可实现含有位段的结构体，将委托对象是否能响应相关协议方法这一信息缓存至其中。

第 24 条：将类的实现代码分散到便于管理的数个分类之中

要点：
– 使用分类机制把类的实现代码划分成易于管理的小块。
– 将应该视为“私有”的方法归入名为 private 的分类中，以隐藏实现细节。

第 25 条：总是为第三方类的分类名称加前缀

要点：
– 向第三方类中添加分类时，总应给其名称加上你专用的前缀。
– 向第三方类中添加分类时，总应给其中的方法加上你专用的前缀。

第 26 条：勿在分类中声明属性

要点：
– 把封装数据所用的全部属性都定义在主接口里。
– 在“class-continuation 分类”之外的其他分类中，可以定义存取方法，但尽量不要定义属性。

第 27 条：使用“class-continuation 分类”隐藏实现细节

要点：
– 通过“class-continuation 分类”向类中新增实例变量
– 通过某属性在主接口中声明为“只读”，而类的内部又要用设置方法修改此属性，那么就在“class-continuation 分类”中将其扩展为“可读写”。
– 把私有方法的原型声明在“class-continuation 分类”里面。
– 若想使类所遵循的协议不为人所知，则可于“class-continuation 分类”中声明。

第 28 条：通过协议提供匿名对象

要点：
– 协议可在某种程度上提供匿名类型。具体的对象类型可以淡化成遵从某协议的 id 类型，协议里规定了对象所应实现的方法。
– 使用匿名对象来隐藏类型名称（或类名）。
– 如果具体类型不确定，重要的是对象能够响应（定义在协议里的）特定方法，那么可以使用匿名对象来表示。

第 5 章：内存管理

第 29 条：理解引用计数

要点：
– 引用计数机制通过可以递增递减的计数器来管理内存。对象创建好之后，其保留技术至少为 1。若保留计数为正，则对象继续存活。当保留计数降为 0 时，对象就被销毁了。
– 在对象生命期中，其余对象通过引用来保留或释放次对象。保留与释放操作分别会递增及递减保留计数。

第 30 条：以 ARC 简化引用计数

在应用程序中，可用下列修饰符来改变局部变量与实例变量的语义：
– __strong：默认语义，保留此值。
– __unsafe_unretained：不保留此值，这么做可能不安全，因为等到再次使用变量时，其对象可能已经回收了。
– __weak：不保留此值，但是变量可以安全使用，因为如果系统把这个对象回收了，那么变量也会自动清空。
– __autoreleasing：把对象“按引用传递”（pass by reference）给方法时，使用这个特殊的修饰符。此值在方法返回时自动释放。

要点：
– 在 ARC 之后，程序员就无须担心内存管理问题了。使用 ARC 来编程，可省去类中的许多“样板代码”。
– ARC 管理对象生命期的方法基本上就是：在合适的地方插入“保留”及“释放”操作。在 ARC 环境下，变量的内存管理语义可以通过修饰符指明，而原来则需要手工执行“保留”及”释放“操作。
– 有方法所返回的对象，其内存管理语义总是通过方法名来实现。ARC 将此确定为开发者必须遵守的规则。
– ARC 只负责管理 Objective-C 对象的内存。尤其注意：CoreFoundation 对象不归 ARC 管理，开发者必须适时调用 CFRetain／CFRelease。

第 31 条：在 dealloc 方法中只释放引用并解除监听

要点：
– 在 dealloc 方法里，应该做的事情就是释放指向其他对象的引用，并取消原来订阅的”键值观察“（KVO）或 NSNotificationCenter 等通知，不要做其他事情。
– 如果对象持有文件描述符等系统资源，那么就应该专门编写一个方法来释放此种资源。这样的类要和其他使用者约定：用完资源后必须调用 close 方法。
– 执行异步任务的方法不应在 dealloc 里调用；只能在正常状态下执行的那些方法也不应在 dealloc 里调用，因为此时对象已处于正在回收的状态了。

第 32 条：编写“异常安全代码”时留意内存管理问题

要点：
– 捕获异常时，一定要注意将 try 块内所创立的对象清理干净。
– 在默认情况下，ARC 不生成安全处理异常所需的清理代码。开启编译器标志后，可生成这种代码，不过会导致应用程序变大，而且会降低运行效率。

第 33 条：以弱引用避免保留环

要点：
– 将某些引用设为 weak，可避免出现“保留环”。
– weak 引用可以自动清空，也可以不自动清空。自动清空（autonilling）是随着 ARC而引入的新特性，由运行期系统来实现。在具备自动清空功能的弱引用上，可以随意读取其数据，因为这种引用不会指向已经回收过的对象。

第 34 条：以“自动释放池块”降低内存峰值

要点：
– 自动释放池排布在栈中，对象收到 autorelease 消息后，系统将其放入最顶端的池里。
– 合理运用自动释放池，可降低应用程序的内存峰值。
– @autoreleasepool 这种新式写法能创建出更为轻便的自动释放池。

第 35 条：用“僵尸对象”调试内存管理问题

要点：
– 系统在回收对象时，可以不将其真的回收，而是把它转化为僵尸对象。通过环境变量 NSZombisEnabled 可开启此功能。
– 系统会修改对象的 isa 指针，令其指向特殊的僵尸类，从而使该对象变为僵尸对象。僵尸类能够响应所有的选择子，响应方式为：打印一条包含消息内容及其接受者的消息，然后终止应用程序。

第 36 条：不要使用 retainCount

要点：
– 对象的保留计数看似有用，实则不然，因为任何给定时间点上的“绝对保留计数”（absolute retain count）都无法反映对象生命周期的全貌。
– 引入 ARC 之后，retainCount 方法就正式废止了，在 ARC 下调用该方法会导致编译器报错。

第 6 章：块与大中枢派发

第 37 条：理解“块”这一概念

– self 也是个对象，因而块在捕获它时也会将其保留。如果 self 所指代的哪个对象同时也保留了块。那么这种情况通常就会导致“保留环”。
–定义在 if 及 else 语句中的两个块都分配在栈内存中。编译器会给每个块分配好栈内存，然而等离开了相应的范围之后，编译器有可能把分配给块的内存覆写掉。于是，这两个块只能保证在对应的 if 或 else 语句范围内有效。这样写出来的代码可以编译，但是运行起来时而正确，时而错误。若编译器未覆写待执行的块，则程序照常运行，若覆写，则程序崩溃。
为解决此问题，可给块对象发送 copy 消息以拷贝之。这样的话，就可以把块从栈复制到堆了。拷贝后的块，可以在定义它的那么范围之外使用。而且，一旦复制到堆上，块就成了带引用计数的对象了。后续的复制操作都不会真的执行复制，只是递增块对象的引用计数。

要点：
– 块是 C、C++、Objective-C 中的语法闭包。
– 块可接受参数，也可返回值。
– 块可以分配在栈或者堆上，也可以是全局的，分配在栈上的块可拷贝到堆里，这样的话，就和标准的 Objective-C 对象一样，具备引用计数了。

第 38 条：为常用的块类型创建 typedef

要点：
– 以 typedef 重新定义块类型，可令块变量用起来更加简单。
– 定义新类型时应遵从现有的命名习惯，勿使其名称与别的类型相冲突。
– 不妨为同一个块签名定义多个类型别名。如果要重构的代码使用了块类型的某个别名，那么只需改相应 typedef 中的块签名即可，无须改动其他 typedef。

第 39 条：用 handle 块降低代码分散程度

要点：
– 在创建对象时，可以使用内联的 handle 块将相关业务逻辑一并声明。
– 在有多个实例需要监控时，如果采用委托模式，那么经常需要根据传入的对象来切换，而若改用 handle 块来实现，则可直接将块与相关对象放在一起。
– 设计 API 时如果用到了 handle 块，那么可以增加一个参数，使调用者可通过此参数来决定应该把块安排在哪个队列上执行。

第 40 条：用块引用其所属对象时不要出现保留环

要点：
– 如果块所捕获的对象直接或间接地保留了块本身，那么就得当心保留环问题。
– 一定要找个适当的时机接触保留环，而不能把责任推给 API 的调用者。

第 41 条：多用派发队列，少用同步锁

要点：
– 派发队列可用来表述同步语义（synchronization semantic），这种做法要比使用 @synchronized 块或 NSLock 对象更简单。
– 将同步与异步派发结合起来，可以实现与普通枷锁机制一样的同步行为，而这么做却不会阻塞执行异步派发的线程。
– 使用同步队列栅栏块，可以令同步行为更加高效。

第 42 条：多用 GCD，少用 performSelector 系列方法

要点：
– performSelector 系列方法在内存管理方面容易有疏失。它无法确定将要执行的选择子具体是什么，因而 ARC 编译器也就无法插入适当的内存管理方法。
– performSelector 系列方法所能处理的选择子太过于局限了，选择子的返回值类型及发送给方法的参数个数都受到限制。
– 如果想把任务放在另一个线程上执行，那么最好不要用 performSelector 系列方法，而是应该把任务封装到块里，然后调用大中枢派发机制的相关方法来实现。

第 43 条：掌握 GCD 及操作队列的使用时机

要点：
– 在解决多线程与任务管理问题时，派发队列并非唯一方案。
– 操作队列提供了一套高层的 Objective-C API，能实现纯 GCD 所具备的绝大部分功能，而且还能完成一些更为复杂的操作，那些操作若改用 GCD 来实现，则需另外编写代码。

第 44 条：通过 Dispatch Group 机制，根据系统资源状况来执行任务

要点：
– 一系列任务可归入一个 dispatch group 之中。开发者可以在这组任务执行完毕时获得通知。
– 通过 dispatch group，可以在并发式派发队列里同时执行多项任务。此时 GCD 会根据系统资源状况来调度这些并发执行的任务。开发者若自己来实现此功能，则需编写大量代码。

第 45 条：使用 dispatch_once 来执行只需运行一次的线程安全代码

在单例模式中所用的 sharedInstance 方法里，static EOCClass *sharedInstance = nil，把该变量定义在 static 作用域中，可以保证编译器在每次执行 sharedInstance 方法是都会复用这个变量，而不会创建新变量。

要点：
– 经常需要编写“只需执行一次的线程安全代码”（thread-safe single-code execution）。通过 GCD 所提供的 dispatch_once 函数，很容易就能实现此功能。
– 标记应该声明在 static 或 global 作用域中，这样的话，在把只需执行一次的块传给 dispatch_once 函数时，传进去的标记也是相同的。

第 46 条：不要使用 dispatch_get_current_queue

要点：
– dispatch_get_current_queue 函数的行为常常与开发者所预期的不同。次函数已经废弃，只应做调试之用。
– 由于派发队列是按层级来组织的，所以无法单用某个队列对象来描述“当前队列”这一概念。
– dispatch_get_current_queue 函数用于解决由不可重入的代码所引发的死锁，然而能用此函数解决的问题，通常也能改用“队列特定数据”来解决。

第 7 章：系统框架

第 47 条：熟悉系统框架

要点：
– 许多系统框架都可以直接使用。其中最重要的是 FOundation 与 CoreFoundation，这两个框架提供了构建应用程序所需的许多核心功能。
– 很多常见任务都能用框架来做，例如音频与视频处理、网络通信、数据管理等。
– 请记住：用纯 C 写成的框架与用 Objective-C 写成的一样重要，若想成为优秀的 Objective-C 开发者，应该掌握 C 语言的核心概念。

第 48 条：多用块枚举，少用 for 循环

要点：
– 遍历 collection 有四种方式。最基本的办法就是 for 循环，其次是 NSEnumerator 遍历法及快速遍历法，最新、最先进的方法则是“块枚举法”。
– “块枚举法”本身就能通过 GCD 来并发执行遍历操作，无须另行编写代码。而采用其它遍历方法则无法轻易实现这一点。
– 若提前知道待遍历的 collection 含有何种对象，则应修改块签名，指出对象的具体类型。

第 49 条：对自定义其内存管理语义的 collection 使用无缝桥街

要点：
– 通过无缝桥接技术，可以在 Foundation 框架中的 Objective-C 对象与 CoreFoundation 框架中的 C 语言数据结构之间来回转换。
– 在 CoreFoundation 层面创建 collection 时，可以指定许多回调函数，这些函数表示此 collection 应如何处理其元素。然后，可运用无缝桥接技术，将其转换成具备特殊内存管理语义的 Objective-C collection。

第 50 条：构建缓存时选用 NSCache 而非 NSDictionary

要点：
– 实现缓存时应选用 NSCache 而非 NSDictionary 对象。因为 NSCache 可以提供优雅的自动删减功能，而且是“线程安全的”，此外，它与字典不同，并不会拷贝键。
– 可以给 NScache 对象设置上限，用以限制缓存中的对象总个数及“总成本”，而这些尺度则定义了缓存删减其中对象的时机。但是绝对不要把这些尺度当成可靠的“硬限制”（hard limit），它们仅对 NSCache 起指导作用。
– 将 NSPurgeableData 与 NSCache 搭配使用，可实现自动清除数据的功能，也就是说，当 NSPuergeableData 对象所占内存为系统所丢弃时，该对象自身也会从缓存中移除。
– 如果缓存使用得当，那么应用程序的响应速度就能提高。只有那种“重新计算起来很费事的”数据，才值得放入缓存，比如那些需要从网络获取或从磁盘读取的数据。

第 51 条：精简 initialize 与 load 的实现代码

要点：
– 在加载阶段，如果类实现了 load 方法，那么系统就会调用它。分类里也可以定义此方法，类的 load 方法要比分类中的先调用。与其他方法不同，load 方法不参与覆写机制。
– 首次使用某个类之前，系统会向其发送 initialize 消息。由于此方法遵从普通的覆写规则，所以通常应该在里面判断当前要初始化的哪个类。
– load 与 initialize 方法都应该实现得精简一些，这有助于保持应用程序的响应能力，也能减少引入“依赖环”（interdependency cycle）的几率。
– 无法在编译期设定的全局变量，可以放在 initialize 方法里初始化。

第 52 条：别忘了 NSTimer 会保留其目标对象

要点：
– NSTimer 对象会保留其目标，直到计数器本身失效为止，调用 invalidate 方法可令计时器实效，另外，一次性的计数器在触发完任务之后也会失效。
– 反复执行任务的计数器（repeating timer），很容易引入保留环，如果这种计时器的目标对象又保留了计时器本身，那肯定会导致保留环。这种环状保留关系，可能是直接发生的，也可能是通过对象图里的其他对象间接发生的。
– 可以扩充 NStimer 的功能，用“块”来打破保留环。不过，除非 NSTimer 将来在公共接口里提供此功能，否则必须创建分类，将相关实现代码加入其中。

后记

记了一遍笔记（不过是将书中的每节要点整理了出来），又粗略阅读了一遍这本书，温故知新。所以，做这份笔记还是很有益处的～