目录
- 核心思想
- 各层职责与优势
- 第一层：接口 (Interface) - 负责“定义契约”，实现“解耦”
- 第二层：抽象类 (Abstract Class) - 负责“封装通用”，实现“复用”
- 第三层：实现类 (Implementation Class) - 负责“具体业务”，实现“扩展”
- 总结
最近看一些开源的代码，发现很多设计都是使用“接口 -> 抽象类 -> 实现类”这种三层结构来最终实现一些业务的设计实现，感觉值得一学。
核心思想
总的来说，采用这种三层结构，是为了构建一个高内聚、低耦合、易于扩展和维护的系统。它通过对不同层次的职责进行划分，应用面向对象的多个设计原则，从而能够应对复杂和多变的业务需求。
各层职责与优势
第一层：接口 (Interface) - 负责“定义契约”，实现“解耦”
接口定义了“能做什么”。它只规定了方法签名，不包含任何实现。
它的核心优势是“解耦”。系统的调用方只依赖于这个稳定的接口，而不关心底层具体实现。这样一来，我们就可以在不改动调用方代码的前提下，随意地更换或增加新的实现策略，这让系统变得非常灵活。
第二层：抽象类 (Abstract Class) - 负责“封装通用”，实现“复用”
抽象类负责实现体系内所有子类都需要的通用逻辑和公共流程。
它的核心优势是“复用”。
- 一方面 它遵循了 DRY (Don't Repeat Yourself) 原则，将公共代码提取出来，避免了在每个实现类中重复编写，大大降低了维护成本。
- 另一方面 通过模板方法模式，它还能定义一个固定的算法骨架，确保所有子类都遵循一个规范、正确的处理流程。
第三层：实现类 (Implementation Class) - 负责“具体业务”，实现“扩展”
实现类负责的是最具体、最核心的业务逻辑。每个实现类都应该有单一的职责。
它的核心优势是“扩展”。这完美体现了“开闭原则”。当我们需要增加一种新的业务实现时，我们只需要新增一个实现类，而不需要修改任何已有的代码。
总结
所以，总结来说，这套“接口 -> 抽象类 -> 实现类”的结构，并不是过度设计，通过这三者的协同工作，我们可以构建出一个职责清晰、扩展性强、维护成本低的健壮系统.
接口解耦了“调用”与“实现”。
抽象类复用了“通用”与“流程”。
实现类隔离了“变化”与“稳定”。
