基于接口而非实现编程
1、如何解读原则中的“接口”二字？
从本质上来看，“接口”就是一组“协议”或者“约定”，是功能提供者提供给使用者的一个“功能列表”。
“接口”在不同的应用场景下会有不同的解读，比如服务端与客户端之间的“接口”，类库提供的“接口”，甚至是一组通信的协议都可以叫作“接口”。
刚刚对“接口”的理解，都比较偏上层、偏抽象，与实际的写代码离得有点远。
如果落实到具体的编码，“基于接口而非实现编程”这条原则中的“接口”，可以理解为编程语言中的接口或者抽象类。
应用这条原则，可以将接口和实现相分离，封装不稳定的实现，暴露稳定的接口。
最大的挑战之一就是需求的不断变化，这也是考验代码设计好坏的一个标准。
越抽象、越顶层、越脱离具体某一实现的设计，越能提高代码的灵活性，越能应对未来的需求变化。
抽象就是提高代码扩展性、灵活性、可维护性最有效的手段之一。
2、如何将这条原则应用到实战中？
在编写代码的时候，要遵从“基于接口而非实现编程”的原则，具体来讲，我们需要做到下面这 3 点
- 1、函数的命名不能暴露任何实现细节。
- 2、封装具体的实现细节
- 3、为实现类定义抽象的接口。具体的实现类都依赖统一的接口定义，遵从一致的上传功能协议。
很多人在定义接口的时候，希望通过实现类来反推接口的定义。
接口的定义只表明做什么，而不是怎么做。
接口设计是否足够通用，是否能够做到在替换具体的接口实现的时候，不需要任何接口定义的改动。
3、是否需要为每个类定义接口？
做任何事情都要讲求一个“度”，过度使用这条原则，非得给每个类都定义接口，接口满天飞，也会导致不必要的开发负担。
这条原则的设计初衷是，将接口和实现相分离，封装不稳定的实现，暴露稳定的接口。
如果在我们的业务场景中，某个功能只有一种实现方式，未来也不可能被其他实现方式替换，那我们就没有必要为其设计接口，也没有必要基于接口编程，直接使用实现类就可以了。
越是不稳定的系统，我们越是要在代码的扩展性、维护性上下功夫。相反，如果某个系统特别稳定，在开发完之后，基本上不需要做维护，那我们就没有必要为其扩展性，投入不必要的开发时间。
