设计模式之美——基于接口编程

抽象类在被继承时体现的是 is-a 关系，接口在被实现时体现的是 can-do 关系
例如，Plane can fly. Bird can fly，应该把 fly 定义成一个接口。

– 参考 《码出自效Java 开发手册》

1. 函数的命名不能暴露任何实现细节。比如， uploadToAliyun() 就不符合要求，应该改为去掉 aliyun 这样的字眼，改为更加抽象的命名方式，比如：upload()。
2. 封装具体的实现细节。比如，跟阿里云相关的特殊上传（或下载）流程不应该暴露给调用者。我们对上传（或下载）流程进行封装，对外提供一个包裹所有上传（或下载）细节的方法，给调用者使用。
3. 为实现类定义抽象的接口。具体的实现类都依赖统一的接口定义，遵从一致的上传功能协议。使用者依赖接口，而不是具体的实现类来编程。

这条原则的设计初衷是，将接口和实现相分离，封装不稳定的实现，暴露稳定的接口。上游系统面向接口而非实现编程，不依赖不稳定的实现细节，这样当实现发生变化的时候，上游系统的代码基本上不需要做改动，以此来降低代码间的耦合性，提高代码的扩展性。

越是不稳定的系统，我们越是要在代码的扩展性、维护性上下功夫。相反，如果某个系统特别稳定，在开发完之后，基本上不需要做维护，那我们就没有必要为其扩展性，投入不必要的开发时间。

---

其实这篇和上一篇可以讲的更好的。首先，我反对接口是has-a的说法，我坚持接口的语义是behaves like(这个其实我也是在某一本书上看的). 咱们看下哪个更通顺和达意，A AliyunImageStorage has a DataStorage. or A AliyunImageStorage behaves like a DataStorage? 除非你在第一句加上 A AliyunImageStorage has some behaviors of DataStorage. 但这基本也就是behaves like的意思了。
第二，我觉得咬文嚼字的确没有什么意义，但为什么说上述话题，难道讲接口的例子不用出现接口多重继承么，引用我之前留言：拿一个C++中举的多重继承例子来说，吸血鬼分别继承自蝙蝠和人，那么吸血鬼is a蝙蝠么？吸血鬼is a人么？所以其实两个都不是，这就是设计上的语义问题。这里缺失了除了is a的另一个概念，behaves like，也就是多重继承的真义实际上是behaves like，也就是接口的意义。A vampire behaves like humans and bats. 而这是接口能多重的原因，一个类可以具有多重行为，但是不能是多种东西。
所以其实也就是说，只有当前模块涉及到抽象行为的时候，才有必要设计接口，才有可能利用接口多重继承的特性来更好的将各种行为分组。

从接口角度来说，接口实现类体现的是，must can do and don’t care how to do