一. 如何理解原则中的接口二字

我们理解基于接口而非实现编程这条原则的时候, 不要与具体的编程语言挂钩, 局限在编程语言的接口语法中, 理解这个原则的关键是理解其中的接口两个字, 我们写代码的时候要遵从基于接口而非实现编程, 具体来讲, 我们要做到以下三点:

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

我们在做软件开发的时候一定要有抽象意识, 封装意识, 接口意识, 在定义接口的时候, 不要暴露任何实现细节, 接口的定义只表明做什么, 而不是怎么做, 而且在设计接口的时候,我们要思考下, 这样接口的设计是否足够通用, 是否能做到在替换具体的接口实现的时候, 不需要依赖任何定义接口的改动.

总之, 我们在定义接口的时候, 一方面, 命名要足够的通用, 不能包含跟具体实现相关的字眼, 另一方面, 与特定实现有关的方法不要定义在接口中.

二. 是否需要为每个类定义接口

做任何事情都要讲求一个“度”，过度使用这条原则，非得给每个类都定义接口，接口满天飞，也会导致不必要的开发负担.至于什么时候，该为某个类定义接口，实现基于接口的编程，什么时候不需要定义接口，直接使用实现类编程，我们做权衡的根本依据，还是要回归到设计原则诞生的初衷上来.

只要搞清楚了这条原则是为了解决什么样的问题而产生的，你就会发现，很多之前模棱两可的问题，都会变得豁然开朗.

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

从这个设计初衷看, 如果我们在业务场景中, 某个功能只有一种实现方法, 未来也不可能被其他方式替换, 那么我们没有必要为其设计接口, 也没有必要基于接口编程, 直接使用实现类就完事了.

越是不稳定的系统, 我们越是要在代码的维护性, 扩展性上下功夫, 反之 , 如果某个系统特别稳定, 在开发完了之后, 基本上不需要在维护, 那么我们没必要为其扩展性, 投入太多的时间.