面向接口编程本质是分离“做什么”与“谁来做”，调用方只依赖接口契约，不依赖具体实现；错误包括硬编码new实现类、参数/返回值用具体类型、条件分支耦合实现；正确做法是统一使用接口类型声明，由工厂或容器注入实现，接口命名聚焦行为，避免暴露实现细节。
面向接口编程不是写个 interface 就完事了
它本质是把「谁来做」和「做什么」彻底分开——调用方只依赖接口定义的行为契约，不关心具体哪个类在干活。一旦你把 new ConcreteClass() 直接写在业务逻辑里，或者方法参数类型写成具体实现类（比如 BlackPrinter），那面向接口就名存实亡了。
常见错误现象：
• 运行时想换打印机，却要改十几处 new ColorPrinter()；
• 单元测试只能用真实数据库连接，因为 DAO 方法返回的是 JdbcUserDao 而非 UserDao 接口；
• 添加新支付方式（如 Apple Pay）时，发现所有订单服务里都硬编码了 if (type.equals("wechat")) {...} else if (type.equals("alipay")) {...}。
- 正确做法：所有对外暴露的方法参数、返回值、成员变量，优先声明为接口类型（如
PrinterFace、UserDao、Payment） - 工厂或 Spring 容器负责提供具体实现，业务代码绝不
new实现类 - 接口方法命名要聚焦行为，避免暴露实现细节（比如用
print(content)，而不是printViaUsb(content)）
为什么必须用接口，而不是抽象类或直接继承？
抽象类会强制子类继承一套固定结构（包括字段、构造逻辑、部分实现），而接口只承诺「能做什么」，不约束「怎么做的」。这在跨领域协作时特别关键——比如支付模块和日志模块完全无关，但都可以实现 Loggable 接口，无需共享父类。
使用场景：
• 多个不相关的类需要提供同一组能力（如 Serializable、Comparable）
• 框架预留扩展点（Spring 的 BeanPostProcessor、MyBatis 的 Interceptor）
• 需要运行时动态切换行为（如不同环境用不同缓存策略：Cache 接口 + RedisCache/CaffeineCache）
立即学习“Java免费学习笔记（深入）”；
- 接口支持多实现，一个类可同时实现
Runnable、Closeable、AutoCloseable，抽象类做不到 - Java 8+ 接口可带
default方法，既保持契约纯洁性，又避免破坏已有实现 - 如果接口开始出现大量
default方法且逻辑趋同，说明它可能正在退化成模板类——该重新审视职责划分了
PrinterFace print(String) 这种简单接口，真能撑起复杂系统？
能，但前提是它只是骨架。真正决定扩展性的，是接口背后的「使用上下文」是否被隔离。比如打印不只是输出字符串，还涉及纸张尺寸、双面、水印、失败重试等。这时候不能一股脑塞进一个接口，而应按正交维度拆解：
-
Printer：核心动作（print(Document doc)） -
PaperSupport：纸张适配能力（supportsA4(),getMaxResolution()） -
FailureHandler：异常策略（onPaperJam(Runnable recovery)）
性能影响很小——JVM 对接口调用的优化已非常成熟（如内联、虚方法表缓存），只要别在热点路径上做无谓的接口层级嵌套（比如 A extends B extends C extends PrinterFace），就不用担心开销。
最容易被忽略的一点：接口的生命周期比实现类长得多
你删掉一个 ColorPrinter 类，顶多影响几处配置；但要是随意修改 PrinterFace.print() 方法签名，所有实现类、所有调用方、所有测试都要跟着动。所以接口一旦发布，就应视作公共契约。
实际建议：
• 新增功能用新接口（如 AdvancedPrinter extends PrinterFace），而非给老接口加方法
• 使用语义化版本控制接口模块（如 printer-api-v2）
• 在接口注释里明确写清线程安全、null 值约定、超时行为等隐含约束
很多团队卡在「扩展性」上，不是不会写接口，而是没守住接口的边界感——把它当草稿纸反复涂改，最后谁都无法稳定依赖。
