你的位置:首页 > 操作系统

[操作系统]第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协议就行。