最小立异原则
如有可能，尽量允许用户将接口功能委派为熟悉的程序来完成
不能委派时，那就效仿
接口设计评估
简洁： 一个事务处理需要的动作时间及复杂度需要较低的上限
表现力： 接口可以触发相当广泛的行为
易用： 易用性同要求用户需要记忆的东西成反比
透明： 用户在使用接口的时候，几乎没有什么问题、数据或程序的相关状态需要记忆
脚本化能力：很容易被其他程序调用
CLI和可视接口之间权衡
CLI：丰富的表现力，高度的脚本化能力，易用性低（需要费劲的记忆），透明度通常也较低
GUI：易用，不能脚本化，处理规模大的问题需要机械性重复操作
长远来看，为了既能服务一般用户，又能服务有经验用户，最好两种接口都提供。
Unix接口设计模式
1. 过滤器模式
程序接受标准输入，转换为某种格式后，再输出到标准输出。过滤器是非交互的。
实例：grep，tr
原则：Postel原则，宽进严出；过滤的时候，不需要的信息也绝不丢弃；不增加无用数据。
2. Cantrip模式
程序没有输入，没有输出，只被调用一次，产生退出状态码。程序的行为只由启动条件来控制。
实例：clear，touch
3. 源模式
程序不需要输入，输出由启动条件决定
实例：ls，ps，who
4. 接收器模式
程序只接纳标准输入，而不产生标准输出。对输入的行为由启动条件决定。
实例：lpr
5. 编译器模式
程序既没有标准输入，也没有标准输出，但是会将错误发到标准错误端。
实例：gcc，gif2png，gzip
6. ed模式
程序具有很强的交互性。
实例：gdb，ftp，sh
7. Roguelike模式
运行在控制台的全屏、可视界面风格，但使用字符阵列显示，而非图形和鼠标界面。
实例：vim，emacs
8. 引擎和接口分离模式
模型、视图、控制器模式
几个变种：配置者/执行者组合（fetchmail/fetchmailconf），假脱机/守护进程组合（at/atd, lpr/lpd），驱动/引擎组合，客户端/服务器组合
9. CLI服务器模式
程序以前端模式出发时，有一个简单的CLI界面读取标准输入并写标准输出；以后台方式运行时，将stdin和stdout连接到专门的TCP/IP端口。
实例：POP, IMAP, SMTP, HTTP
10. 基于语言的接口模式
GUI前端同CLI微型语言后端结合，程序往往拥有一个的内嵌脚本语言。
网页浏览器作为通用前端
沉默是金：喋喋不休的程序往往不能跟其他程序很好的合作，用户屏幕的纵向空间是宝贵的，垃圾信息对用户带宽的无谓消耗。，
长时间的操作要提供进度条。
