from: http://z.ihu.im/u/BZp(7

1、依赖倒置原则

依赖倒置的意思，是不要想象别人应该怎么用你的API、以及用你的API做什么；而是“倒”过来想，我的API对外提供了一个什么样的抽象、这个抽象是否够好、够简洁，有没有把不必要的细节暴露给用户。

比如说，之前我所在的公司做了个类似电子商城的东西，其它项目组做出产品，就放在这个商城里面销售。

那个商城团队就犯了干涉他人实现的大忌：他们非要了解其他项目组的逻辑，才知道如何才能把别人的产品上架销售。不要这样。

这种做法就导致两个团队耦合过重；且新产品和老产品逻辑无法兼容、甚至因为修改逻辑去迎合新产品，导致老产品销售逻辑出现问题——又因为怕老产品出现问题，于是不得不逼新产品去适应老产品的流程，而不管两者差别有多大。

这就导致，我们经常花1个月实现了一个新产品；为了把它上架却经常需要3个月甚至超过半年——并且，商城团队和其它项目团队都必须加班、修改逻辑，甚至经常因为商城方提出的诡异逻辑/需求而出现摩擦（这伙人傻的……我都忍不住发过几次火……

实在看不下去，我就给了一个方案，要求商城团队修改。

这个方案基于依赖倒置原则，要求商城对外提供一个商品的抽象；商品的定义是有名字有价格、通过销售转移所有权的逻辑实体。

如此一来，任何项目想要上架，只要给自己起个名字、定个价格、用html或某种富文本格式或商城项目组喜欢的任何格式提供一段商品介绍、最后再提供一个“所有权成功转移给xx用户”的回调接口即可。双方从此再不需要哪怕一个字的交流。

这个接口可以永远不修改哪怕一个字节，足以支持任何商品种类的交易。

（事实上，我们团队就是按这个要求写程序的。写完再和商城团队扯皮。这可以避免他们动辄增加的猪逻辑/需求影响到我们的内部结构：随便他们要什么，我们都可以弄个空逻辑或者不同商品规格搪塞过去）

但商城团队觉得一旦做成这样，他们以后就没事可干了，所以拒绝修改……

好在，后来他们集体辞职了。

——如果你的接口不能稳定，那么你一定违反了依赖倒置原则，或者是做了一个超烂的抽象。

——至于什么叫好抽象，请参考KISS原则

2、完整且最小原则

完整，就是接口的功能要完整，该有的功能必须有；最小，是接口功能没有冗余，不要接口A提供的功能，用一点外部逻辑再加上接口B或者接口B+接口C也能实现。

当然，这是一个比较理想化的指标。某些时候，为了易用性或者性能，是可以甚至必须做一些更简单、方便、易用，但加起来却不是最简的接口的。

但，这个完整且最小的接口必须找出来。它是一切的基础，也体现了开发者是否已经做出了一个清晰的抽象。

有了它，其它可以以后慢慢补；但如果没有这个基础，什么易用、简洁，都不过是扯淡。

我宁可用一个繁琐、难用、难理解，但可保证不变的接口，也不想碰做点简单的活计非常方便、易用，但根本没法实现稍难的需求、并且不能保证稳定的接口。

事实上，两者的差别就在于有没有好的抽象；而一旦有了好的抽象，哪怕想做得繁琐、难用、难理解，都不是容易的事。

总结：有了好的抽象，接口才可能稳定；然后找出完整且最小的接口，那么只要抽象不变，这个接口就绝对稳定；最后，在这个基础之上，做出易用、易理解的接口。