第3章接口与API设计52条笔记

第3章 接口与API设计 52条笔记

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

Objective-C 没有其他语言那种内置的命名空间机制 。鉴于此，我们在起名时要设法避免潜在的命名冲突，否则很容易就重名了。如果发生命名冲突 naming clash ,那么应用程序的连接过程就胡出错。

避免此问题的唯一做法就是变相实现命名空间：为所有名称都加上适当的前缀。

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

把这种可为对象提供必要信息以便其能完成工作的初始化方法就做 指定初始化方法 designated initialzier.

如果创建实例的方法不止一种，那么这个类就会有多个初始化方法。不过要在其中选定一个作为designated initializer ，令其他初始化方法都来调用它。

上面几个初始化方法中，initWithTimeIntervalSinceReferenceDate:是 designated initializer.

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

该模式的主旨是 ： 定义一套接口，某对象若想接受另一个对象的委托，则需要遵从此接口，以便成为其委托对象 delegate.而这另一个对象则可以给其委托对象回传一些信息，也可以在发生相关事件时通知委托对象。

一般通过协议 这项语言特性来是实现此模式，整个Cocoa系统框架都是这么做的。

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

类中经常容易填满各种方法，而这些方法的代码则全部堆在一个巨大的实现文件中。

通过Objective-C的分类机制，把类代码按逻辑划入几个分区中，这对开发与调试都有好处。

把个人信息建模为类。

可以用分类机制把刚才的类改写成下面这样：

现在，类的实现代码按照方法分成了好几个部分。所以说，这项语言特性当然就叫做分类 啦 。

使用分类机制之后，依然可以把整个类都定义在一个接口文件中，并将其代码写在一个实现文件中。可是随着分类数量增加，当前这份实现文件很快就会膨胀。此时，可以把每个分类提取到各自的文件中去。

以EOCPerson为例，可以按照其分类分成以下几个文件：

通过分类机制，可以把类代码分成很多易于管理的小块，以便单独检视 。使用分类机制之后，如果想用分类中的方法，那么要记得在引入EOCPerson.h时一并引入分类的头文件。

虽然稍微有点麻烦，不过分类仍然是一种管理代码的好方法。

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

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

属性是封装数据的方式。尽管从技术上说，分类也可以声明属性，但这种做法应该尽量避免。

关联对象能够解决在分类中不能合成实例变量的问题。

这样做可行，但不太理想。要把相似的代码写很多遍，而且在内存管理问题上容易出错，因为我们在为属性实现存取方法时，经常会忘记遵从其内存管理语义。

尽管这个方法不坏，但笔者不推荐。

把属性定义在主接口中要比定义在分类里清洗得多。

至于分类机制，则应将其理解为一种手段，目标在于扩展类的功能。

有时候只读属性还是可以在分类中使用的。

由于获取方法并不访问数据，而且属性也不需要由实例变量来实现，所以可以像下面这样来实现分类：

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

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

协议定义了一系列方法，遵从此协议的对象应该实现他们。于是，我们可以用协议把自己所写的API只中的实现细节隐藏起来，将返回的对象设计为遵从此协议的纯id 类型。

在定义受委托者 delegate这个属性时，可以这样写

@PRoperty (nonatomic ,weak )id <EOCDelegate>delegate;

由于该属性的类型是id<EOCDelegate>，所以实际上任何类的对象都能充当这一属性，即便该类不继承自NSObject也可以，只有遵循EOCDelegat协议就行。