Martin Fowler最近的两篇Blog，推荐阅读

《人本接口》与《最小接口》
http://blog.csdn.net/mfowler/archive/2006/10/19/1340358.aspx

http://blog.csdn.net/mfowler/archive/2006/10/19/1340364.aspx

一个类的接口如何设计？这个问题很值得探讨。

我在设计DJ的时候，也考虑过这个问题，按照Channel的思想，简单的Channel可以组合起来，成为复杂的Channel，这样既能够满足最小接口的精简原则，又能够满足人本接口的方便原则。

欢迎大家讨论

感觉这个问题，关键是用在那里?

如果是 准备 标准化的 核心的基础库(这个在这里好像没有什莫讨论的必要，我看不出坛子里谁有从事这方面的斤两)，
我倾向最小接口，通过概念泛化 进行 胶合，与STL的iterator比较类似。

如果及用及扔的库，或者说，准备不断演进的框架,开源lib，接口肥大点也无所谓，物竞天择，最后可以淘汰一批接口。

问的好！拓宽点说  很多技术看上去都不错。问题用在那里？什么样情况能够用？什么情况下不能用。这个方面的资讯实在是少的可怜。

估计 老马 也犯晕了 ：“正反双方都不乏闪亮论点。就我个人而言，我倾向于人本接口一方，尽管我觉得它的难度确实更高。”

那个难度高，不是很显然吗？

这可能和设计哲学有关。 Ruby秉承自Perl的仿自然语言多样性和所谓最小惊讶原则，所以喜欢搞很多方法别名。这个东西有利有弊，好处是减少记忆负担，不用老去查API了，很多用法有个大约印象再猜一下就出来了。坏处是命名空间更加拥挤，名字冲突风险有所提高。

网上有个评论很经典，老马不应该拿一个具体类和一个接口去比较。
要比较，就去和LinkedList比，这个实现了6/7个接口，实现的方法数目不比ruby的那个少,所谓的first/last也都有。
学了ruby之后，看java代码的时候不带有色眼镜，也把ducking type的那一套套到java代码上去,比如一个LinkedList就提供了一个隐含的ILinkedList接口，那就一切ok乐。
记得有个C#大佬死命的推荐具体类，建议除非特殊情况，只要能够用具体类的地方，都不要搞出一个接口来. 其实也非常贴合ducking type的思想精髓，在java/C#中，interface实际上是显式的接口，看着不顺眼就不用，直接使用依着于具体类的隐式接口吧。好处是，显式接口一旦发布，修改是很忌讳的，而具体类的公共方法就没有这个心理负担，虽然实质上是一回事情。
不过这些都是TDD/测试先行带来的间接效果，没有这个前提，别的都是白扯.

老马是在犯迷糊,java中，有些东西不直接在自己的类实现，无非是
把负担转嫁到另外的地方去,比如放到Collections,难道就不是放了?
还有象oscore的项目，我们在项目中写代码，也常常有重复一些小功能，虽然这些小功能只需要几行代码就能搞定，但是每次在很多地方
重复这几行也不好。所以象判空isEmpty(String str) ==>
if(str == null || str.trim.equals("") ) {
  return true;
}
isEmpty(Collection c) ==>
if(c == null || c.size == 0) {
  return true;
}
这样的一些封装就很有必要。

从艺术上讲自然是最小接口。
从实际上讲就说不清了，似乎得从为什么要用接口出发了。

倾向于人本，并且认为接口的不变性有点过于理想化，当认为某个接口项不用再维护的话，砍掉它！接口的意义应该是比较长的一段时间不变，而不是终生不变。

唯一不变的就是变化。

哈，碰到一个同好阿，不过我是在cpp中。

感觉是两个角度看问题：人本接口倾向于client (Assembler)，最小接口倾向于supplier (Implementation)。

Martin Fowler倾向于人本接口，个人倾向于最小接口。

人本接口容易把类搞成巨大，最精华的算法反而容易被忽视掉，trouble shooting也就更难。而且人本接口违反了OO的基本原则OCP。

其实可以这样做：搞两个接口，一个是给client用的，搞成人本接口，内部实际操作dispatch到另一个给supplier用的最小接口上。这样supplier可以把自己的最小接口完全搞成一个内部实现接口，对用户来说是透明的。而client接口负责组装那些功能逻辑。这样指责更分明，不会造成接口污染。