《设计模式之美》理论六：为什么基于接口而非实现编程？有必要为每个类都定义接口吗？

王争《设计模式之美》学习笔记

解读“基于接口而非实现编程”

如何解读原则中的“接口”二字？

1. 不要局限在编程语言的“接口”语法中。
2. 接口”就是一组“协议”或者“约定”。
3. 上游系统面向接口而非实现编程，不依赖不稳定的实现细节，降低耦合性，提高扩展性。
4. 可以解读为“基于抽象而非实现编程”。
5. 好的代码设计，不仅能应对当下的需求，而且在将来需求发生变化的时候，仍然能够在不破坏原有代码设计的情况下灵活应对。

如何将这条原则应用到实战中？

1. 作者以一个上传图片的代码举例。
2. 封装了上传图片到阿里云的的类，以后图片不再存储到阿里云而是私有云等，就要修改代码。
3. 还有类中的函数命名暴露了实现细节。
4. 上传的实现过程不一致的，以后更改存储，这里面的实现细节都要修改。

“基于接口而非实现编程”的3点原则

1. 函数的命名不能暴露任何实现细节。
2. 封装具体的实现细节。
3. 为实现类定义抽象的接口。

如何来做权衡，怎样恰到好处地应用这条原则

1. 过度使用这条原则，非得给每个类都定义接口，接口满天飞，也会导致不必要的开发负担。
2. 如果在我们的业务场景中，某个功能只有一种实现方式，未来也不可能被其他实现方式替换，那我们就没有必要为其设计接口，也没有必要基于接口编程，直接使用实现类就可以了。
3. 如果某个系统特别稳定，在开发完之后，基本上不需要做维护，那我们就没有必要为其扩展性，投入不必要的开发时间。