API设计原则

1. 使用本地方言，不要使用外部约定

我在API设计里经常见到使用外部协议这样的错误。API属于一个平台或者一个开发者生态系统，通常你无法简单地使用使用别的平台的惯用方法。这样还会造成现有代码的污染，并且会导致你的同事的生产力的下降。

2. 解耦

所有的组件都不应该单为本项目而设计。如果它有GUI的话，至少应该有默认的显示内容。一个很有效的方法就是每一个组件都单独开发，按你自己的想法去做，原理不相关的A类，强迫自己只使用自己的API。

3. 所需设置应该初始化参数

如果需要设置什么，千万别犹豫。如果你什么返回结果都不需要的话，就返回0吧。

4. 允许访问初始化参数

这条原则和之前的联系紧密，不要把这些变量封装死了，记得留下通过属性访问它们的方法。注意它们会不会被修改。

5. 给文件和预设值注释

实际上，你一般不会给一个组件单独的文档，如果你真的没有准备说明文档，那么注释和demo就是你最好的说明文档。

尽量简洁，但是详细。

专业点，假设事情是安全的，别写废话。

特别要注意初始值，在头部进行注释说明永远比在实现里说明更好。

6. 代码量保持在3行内

你的代码应该需要使用最小的代码来结合。你至少需要在三行代码内实现测试目的。

这三行是：

实例化

基本设置，让它能够显示最基本的东西或者做最基本的活动

显示否则激活

7. 臃肿的demo通常意味着破碎的组件

你的demo的代码量直接反映了你的组件的质量（越小越好）。

8. 预测定制化场景

使用最合适的初始化设置来满足大多数用户的需求，这样就可以跳过第一次设置了。好的应用总是武断的。让委托方法和代码结构来应付其它用户吧。

9. 更多的属性，更少的方法

10.在控制里使用控制

一个简化你的API和组件实现的好方法就是重复使用已存在的组件。统一的表现并不意味着你不可以建立已存在的组件（实际上，重复利用组件是软件工程的一项基本原则。）

11.你方便我也方便

你是不是也是在实现方法时总是自觉地将它设为private？先想想你还会不会重用你的代码

12.迟早你会往自己的代码中添加magic

使用#define来让你的数字更易于理解和表现。

委托协议就是一个很不错的MVC模式实现。

13.限制必须的委托方法数

在确定哪些委托方法是必须的时必须非常小心，太多的必须方法会导致：

默认设置的可怜选择

代码中有太多的政策

好的委托方法都应该只有很少的委托方法。

14.为可访问性而设计

从一开始就需要非常重视可访问性，如果你遵循“在控制中使用控制”原则的话，相信这是非常容易做到的。

15.为参数使用语义对象

这不仅可应用于协议，但是对于协议来说，这非常重要。甚至在你的实现中更麻烦，几乎所有东西都有对象和结构体，准备好使用它们。

16.不符合语法的话就增强API

17.强调重点很有趣

18.可选方法不是承诺

20.在询问方法中首先使用特殊的参数

21.通知方法中优先发送者

22.如果协议破碎，那就抛弃它

23.通知遵循委托方法

24.通知里的用户信息尽量开放