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.通知里的用户信息尽量开放
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值