在软件开发中，总要制定这样那样的接口，一般来说分为两种：
1、面向用户的操作接口
2、面向开发者的程序接口
对于这两种接口的定义规范，我们应该遵循下面两点：
1、对于用户的接口（操作接口）：越简单越好。
现在的设计讲究易用性，越简单越易用的功能接口越能被用户接受，反之用户就可能远远避开。
如在某blog上看到这样的一个示例：
一个软件，用户在输入一条记录后必须点击一下输入按钮这条数据才能真正输入，如果仅仅只需要输入一条记录那么这样也没什么，但很多时候用户一次性需要输入成百上千条数据，这样每输一条数据就点击一下输入按钮，估计没有几个人能不疯掉。这个可能是软件设计者因为技术或其他原因设计的这样一个用户使用接口。而这样来要求用户，就有些过分了，用户如果欣然接受你的软件那就怪了。类似这种设计应该学习excel，用户输入一条数据后按下enter自动进行下一个输入区。
当然为用户提供越灵活自由简单的接口，后台的处理逻辑可能会越复杂，但是如果能够给用户带来更好的体验很多时候这都是值得的。
2、对于开发者的接口（大多是程序接口）：越复杂越详细越好
为什么不是越简单越好呢？因为刚才说了，这样后台逻辑处理就比较麻烦，开发难度高。
因此从开发成本和面向对象技术中的对象负责自己的原则来看，应该为每个部分制定详细的接口规范。
这样可以减少每个部分之间的耦合性，从而降低开发的难度，节约成本，。
举个例子：一个设备控制模块，他的一个使用规范是这样定义的：在调用控制命令之前，必须初始化通讯模块。有的人可能会问，难道我不能在控制软件模块加一个判 断，发现通讯模块不能工作，就自己调用一下通讯模块初始化命令的功能不行吗？我们从成本角度考虑就会发现这个建议确实不行。原因是，这个不但多写了一段代码，而且还增加了模块之间的不必要的耦合度。况且，照这个思路其他模块也许也要加上这个通讯模块初始化命令，更是错上加错了。从职责角度考虑，我们给设备控制模块附加上初始化通讯模块的功能，显然也是有问题的。
越复杂的项目越要有复杂的规范，否则就可能会变得很难维护。
原文：http://blog.csdn.net/acloudhuang/archive/2007/12/14/1936057.aspx