最小接口

所谓最小接口，其设计风格与人本接口形成鲜明对照，它背后的主旨是设计一套API不仅能满足用户完成所有操作的需求，还要把这种能力积聚到一个最精简的方法集合上。（两者的区别请参考人本接口里的例子。）

拿人本接口里的例子“Ruby-Array VS Java-List”来说，既然List已经有了取索引位置处元素的方法，又能获得链表的长度，那就没必要再加上first和last方法了—— first和last的效果用已有接口就能实现，因此它们属于便利方法（convenience methods），不过，推崇最小接口的设计者对便利方法也并非一概避免，只是一个便利方法要想跻身为最小接口的一员需要先跳过一个很高的标杆。

我们已经讨论过人本接口了，下面说一下最小接口的基本原则。

学习接口怎么用是要花时间的，如果一个class接口很庞大，用户可能对它的第一印象就不是很好，想用好它没准就很不容易了。如果能保持接口被限制在一个窄小而聚焦的方法集合上，那么用户要了解这是个什么class、它有哪些功能就相对容易了。

“聚焦”对class设计者也很重要。设计class时的一个常见问题就是让一个class做太多事情。把注意力集中在最基本的操作上能帮助class避免赘肉缠身，让它专心做一件事并把这件事情做好。

如果选择人本方案，一个方法只要可能被某人用到，你就会把它添上，这样不断添加方法，最后多得没完没了，何处是个头儿呢？因此，为了避免方法爆炸，必需得有个指导原则。如果把“有用的就是需要的”作为设计人本接口的指导原则，确定什么是“有用的”本来就见仁见智，很难说清。而最小接口的原则就简单多了——如果一个操作用已经有的方法能完成，那么就无需再新添一个。

（需要注意，找出哪些方法是有用的——这个问题对编写公开发布的类库的人比对编写应用代码的人意义更重大。写应用代码时，因为是限制在一个封闭的系统范围内，你很清楚一个接口有哪些用法。）

如果你用的是静态类型的纯接口（比如Java和C#里的interface关键字），那么保持方法总数较小的另一个原因是为了减轻接口实现的负担。如果不得不实现的方法数量庞大，那可真是不小的工作量。（可以用抽象类(abstract class)以混入(mixin)的方式来减轻这种负担。）

在用一个最小接口class时，如果需要更多功能，你可以借助其他class。例如在Java中你要想翻转一个List或给它排序（这些操作都是Ruby Array的常规方法），可以借助Collections这个工具类。

如果你是在编写一个库，一旦发布，就很难再从中去掉什么东西了。因此，最好是先天不足，后天逐渐丰富，这样要强于先天营养过剩长成胖子，之后想减肥也减不下来