接口定义行为契约，强调“能做什么”，用于策略、观察者等模式实现解耦与多态；抽象类提供部分实现，体现“是什么”关系，适用于模板方法、构建器等需共用逻辑的场景。两者核心区别在于设计意图：接口支持多实现，侧重能力规范；抽象类允许代码复用，适合有共同行为的类继承。实际开发中常结合使用，如List与AbstractList，既保证灵活性又降低实现成本，符合开闭原则，是构建可扩展系统的关键基础。
接口与抽象类是Java中实现抽象化的重要机制，在设计模式的应用中扮演着核心角色。它们不是简单的语法工具，而是面向对象设计思想的体现，尤其在构建可扩展、可维护的系统架构时至关重要。
接口：定义行为契约
接口在Java中用于声明一组方法签名，不包含实现（Java 8之后允许默认方法和静态方法）。它强调“能做什么”，而不是“如何做”。通过接口，可以实现多态和解耦。
在设计模式中，接口常用于：
- 策略模式：不同算法实现同一接口，客户端可动态切换策略。
- 观察者模式：观察者实现统一接口，被观察者无需了解具体类型，只需调用接口方法通知变化。
- 工厂模式：工厂返回接口类型对象，隐藏具体类的创建细节，提升灵活性。
使用接口让系统更易于扩展。新增功能只需实现接口，无需修改原有代码，符合开闭原则。
立即学习“Java免费学习笔记（深入）”；
抽象类：提供部分实现的基础模板
抽象类用于表示一种“是什么”的关系，它可以包含抽象方法和具体实现。适合多个子类共享通用逻辑的场景。
在设计模式中的典型应用包括：
- 模板方法模式：抽象类定义算法骨架，子类实现具体步骤。例如流程处理中固定流程但可定制某些环节。
- 钩子方法：抽象类提供默认空实现的方法，子类可选择性覆盖，控制执行流程。
- 构建器模式中，抽象构建器类定义通用构建步骤，具体构建器继承并实现细节。
抽象类更适合有共性行为且需要代码复用的情况，同时保留一定的扩展空间。
接口 vs 抽象类：设计决策的关键点
选择接口还是抽象类，取决于设计意图：
- 若关注行为规范，且希望一个类能“具备多种能力”，优先使用接口。
- 若存在共同状态或行为逻辑，且子类属于同一类别，抽象类更合适。
- Java不支持多继承，但允许实现多个接口，因此接口在组合能力上更灵活。
- 从版本演进看，接口更稳定，添加新方法可能破坏实现类（除非用default），而抽象类可在子类中逐步扩展。
结合使用：发挥最大设计价值
实际项目中，接口与抽象类往往协同工作。例如：
- 先定义接口作为对外服务契约。
- 提供一个抽象类作为基础实现，包含公共逻辑，帮助开发者快速接入。
- JDK中的java.util.List接口与AbstractList抽象类就是典型例子。
这种“接口+抽象基类”的模式兼顾了灵活性与易用性，是优秀框架的常见设计手法。
基本上就这些。理解接口与抽象类的本质差异和协作方式，是掌握设计模式精髓的基础。关键在于根据业务语义和扩展需求做出合理选择，而非机械套用语法结构。
