尧图网页设计 
1. 接口是什么从USB插口到代码契约如果你用过电脑一定见过USB接口。这个接口本身不包含任何功能它只定义了一套尺寸和电气的规范任何一个厂商生产的U盘、手机、读卡器只要遵循这个规范接上去就能工作。Java里的接口也是这个逻辑——它定义了一套规则任何类只要声明实现了它就必须按这套规则办事。在Java面向对象的体系里接口是一个极其常见又容易被忽视的关键字。很多初学者在学到这里时觉得接口无非就是“把抽象类的抽象部分拎出来”这种理解不能说错但会把接口用窄了。接口真正的价值不在于语法本身多复杂而在于它提供了一种“约定优于实现”的组织方式让代码可以按能力来组合而不是按继承树来纵向绑定。这个系列前面聊过类、对象、继承和多态。你应该有印象Java的类只支持单继承一个类只能有一个父类。这个设计极大降低了对象模型的复杂度避免了多继承带来的菱形冲突问题但也让“复用能力”这件事变得有些局促——假设我有一个可以飞行的能力想让飞机类和超人角色类共享如果只能靠继承就得强行给它们找一个共同的父类这个父类往往非常牵强甚至会污染整个继承设计。接口的出现正是为了解决这类问题。它把“是什么”继承体系和“能做什么”能力清单分开了飞机是交通工具超人是角色它们都可以“飞”而“飞”这个能力用接口来表达就再合适不过。实现同一个接口的类可以来自完全不同的继承分支这打破了单继承的局限性也让代码的表达方式更灵活。1.1 接口强调“能做什么”而不是“是什么”这句话值得反复揣摩。抽象类和接口的区别核心就在这。当你在设计一个抽象类时你实际上是在定义“这一类事物的共同底座”。比如抽象类Animal里面有属性name、age有具体方法eat()有抽象方法move()它强调的是一类动物共有的特征和状态。而接口比如Flyable里面只写一个fly()方法它不关心谁在飞、怎么飞只表达一个事实实现这个接口的东西一定能飞。所以面向对象设计里有一句经典的口号面向接口编程而不是面向实现编程。依赖一个接口意味着你只关心对方能提供什么而不关心它内部是怎么实现的。这样未来换实现类、扩展新实现上游代码都不需要改动。1.2 接口是Java实现多态的另一条路径之前讲多态时你看到的多态通常是父类引用指向子类对象。接口同样可以做到类似的效果而且适用范围更宽。你可以声明一个接口类型的变量然后让它指向任何一个实现了这个接口的类的对象调用时执行的是具体实现类里的方法。这种通过接口实现的多态在日常开发中使用频率极高。例如一个支付系统你有微信支付、支付宝支付、银行卡支付三个类它们都实现同一个Payment接口业务代码只需要面向Payment接口来写完全不需要关心当前用户选的是哪种支付方式。当我们需要接入新的支付渠道时只需要新增一个实现类就够了原有的支付流程代码一行不用动。这种设计上的弹性就是接口存在的意义之一。2. 动手写第一个接口语法拆解与隐藏规则聊清楚了接口的定位我们来看语法。接口的定义用interface关键字比类简单很多但细节都在“隐藏规则”里。2.1 基本定义与实现看一个最简单的例子public interface Flyable { void fly(); }它定义了一个名为Flyable的接口里面有一个抽象方法fly()。注意在接口里写方法时即使你不加public abstract这两个修饰符也是默认存在的。换句话说接口里的抽象方法本质上就是public abstract的。一个类要实现这个接口用implements关键字public class Bird implements Flyable { Override public void fly() { System.out.println(鸟儿扇动翅膀飞行); } } public class Plane extends Machine implements Flyable { Override public void fly() { System.out.println(飞机喷气推进飞行); } }可以看到Plane继承了Machine类同时又实现了Flyable接口。类和接口的组合让能力叠加变得很自然这也是接口最核心的用法。2.2 必须实现所有抽象方法吗——是的除非你是抽象类一个普通类实现接口后必须实现接口里的所有抽象方法否则编译器会报错。这里有两个例外第一如果实现类也是抽象类它可以选择只实现一部分方法把剩下的继续声明为抽象方法交给它的子类完成。第二如果实现的是Java 8之后带默认方法的接口后面会细说默认方法不需要实现。所以编译期的规则很简单一个具体类收到接口的“契约”就必须全盘接受。漏写一个方法IDE里就会出现红色波浪线这是一个很常见的初学者报错。2.3 接口里的“隐形修饰符”这是我每次讲接口都要单独强调的地方。接口里的成员变量不管写不写修饰符实际上都是public static final的。也就是说接口里没有真正的“实例变量”只有常量这个常量属于接口本身不随实现类对象变化实现类可以引用它但不能重新赋值。看代码public interface SpeedLimit { int MAX_SPEED 120; // 实际等于 public static final int MAX_SPEED 120; } public class Car implements SpeedLimit { public void show() { // MAX_SPEED是常量属于接口所有 System.out.println(限速 MAX_SPEED); } }反过来接口里的普通方法默认都带public abstract。这也意味着你在实现接口方法时不能把方法的访问权限缩小比如不能写成private void fly()因为实现方法必须满足父级方法的可见性约定这是Java的规则。2.4 接口可以继承接口一个类可以同时实现多个接口刚才说过类只能单继承但接口不受这个限制。一个接口可以通过extends继承另一个接口获得它所有的抽象方法声明public interface AnimalAction extends Eat, Moveable { void sleep(); }而一个类可以同时 implements 多个接口这是Java用来弥补单继承能力不足的重要手段public class Robot implements Flyable, Chargeable, Recordable { // 需要实现三个接口里所有的抽象方法 }多实现的组合能力正是很多框架设计中依赖接口让对象扮演多重角色的基础。设计模式里的适配器、装饰器都大量依赖接口的这种多组合特性。2.5 空接口也是一种设计接口里可以一个方法都没有比如java.io.Serializable、Cloneable就是典型的空接口标记接口。它们表面上看没有任何要求实际上是在给对象打标签告诉虚拟机或工具类“这个类的对象可以被序列化”或“可以被克隆”。这是接口一个非常有意思的亚种面试里也偶尔会问到。3. Java 8之后的接口新能力默认方法、静态方法与私有方法如果你在用的Java版本是8或更高那接口的能力远不止“纯抽象”这么简单。Java 8之后接口家族多了三个重要成员这也是初学者容易把接口和抽象类搞混的根源之一。3.1 默认方法default method接口升级不再折腾所有实现类在Java 8之前接口几乎对所有方法一视同仁都必须被实现。这带来一个很现实的问题——假设你的接口已经被几十个类实现了某天你需要往接口里加一个新方法那么所有实现类都必须同步修改否则编译报错。对于框架开发者来说这种“接口演进”的代价极其可怕。默认方法解决了这个问题。用default关键字修饰的方法可以自带实现体实现类可以直接用也可以覆盖它完全不会影响其他已有实现类。public interface Payment { void pay(double amount); // 默认方法所有支付方式都能共用这套校验逻辑也可以各自覆盖 default boolean checkAmount(double amount) { return amount 0 amount 100000; } }这样一来新的Implementer类的实现负担大幅减轻同时老代码也能无痛升级。多个接口同时提供同签名默认方法的时候就会触发冲突问题。Java给出的规则是优先覆盖冲突出具体来说分三步——第一步看实现类自己有没有覆盖这个方法有就直接用第二步看父子接口之间的优先级子接口的默认方法优先于父接口第三步如果多个互不相关的接口都有同名默认方法实现类必须自己重写这个方法否则编译报错。3.2 静态方法接口里也能有工具方法Java 8同时允许在接口里定义static方法static方法属于接口本身不参与继承也不能通过实现类对象调用。它通常用来放一些和这个接口概念密切相关的工具方法。public interface MathOperations { static double toRadians(double degrees) { return degrees * Math.PI / 180.0; } }调用时只能写MathOperations.toRadians(180)这个和类的静态方法很类似。3.3 私有方法Java 9默认方法之间的代码复用Java 9之后接口还允许定义private方法主要用途是抽取出默认方法之间重复的公共逻辑。这种private方法只能被接口内部的默认方法或静态方法调用对外不可见从而实现了“内部复用而不暴露”的效果。3.4 接口与抽象类现在什么时候该用谁默认方法出现后接口和抽象类看起来都有“具体实现”了边界确实模糊了一些但定位依然清晰对比维度接口抽象类关键词interface / implementsabstract class / extends继承数量一个类可实现多个接口一个类只能继承一个抽象类成员变量只能是常量public static final可以有实例变量、成员变量构造函数没有构造函数有构造函数方法形态抽象方法、默认方法、静态方法、私有方法抽象方法、具体方法、静态方法设计语义强调“能做什么”能力契约强调“是什么”类型根基演进成本默认方法可以平滑扩展加方法需要谨慎评估所有子类我个人的经验是优先考虑接口只有当需要共享状态、共用成员变量、提供模板骨架时才考虑抽象类。JDK本身很多设计也是这样做的比如List接口加了一堆default方法而AbstractList抽象类则提供了默认实现骨架。4. 实战面向接口编程的三个典型场景语法学完得看它在真实项目里怎么发挥作用。我在实际开发里最常见到接口承载三大类职责分开说。4.1 DAO层接口让业务代码与数据源解耦在一个业务系统里数据访问层DAO几乎一定会先用接口定义操作再提供具体实现。比如订单模块你先定义OrderDao接口里面写上insert、findById、updateStatus这些方法然后MySQL的订单实现类去实现它。这样业务层依赖的是OrderDao接口而不是某个具体的数据库实现类。以后如果要从MySQL迁到PostgreSQL或者换一个ORM框架只需要新增一个实现类业务代码甚至不需要感知到变化。这种把“变化点”隔离在接口后面的做法是大型项目能持续演进的基石。4.2 策略模式算法随时可替换策略模式是最容易理解接口价值的场景之一。假设你的系统支持多种运费计算规则普通快递、冷链、同城速递价格算法各不相同。如果不做设计你大概率会写出一个巨型方法里面塞满if else。每次增加新配送方式都要改动这段核心逻辑风险极高。用接口重构的思路是这样定义ShippingStrategy接口里面一个方法calculate(Order order)每种配送方式写一个实现类调用方只需要持有接口引用在运行时根据配置或用户选择塞进来一个具体实现。加新策略时添加新类即可原有代码不动完美符合开闭原则。4.3 回调接口框架把控制权交还给业务方回调是接口的另一大应用场景。框架比如定时任务框架、消息队列消费者、GUI事件系统本身不知道你的业务逻辑它只能按照预定流程执行然后在合适的时机调用你提供的接口方法。这些方法就是回调。Spring里最常见的ApplicationContextAware、BeanNameAware都是这个套路定时任务框架里定义Job接口你实现execute方法框架在触发时间点调用它。通过接口回调框架和业务方实现了松耦合谁都不用强依赖谁。4.4 一个小型重构案例从具体类依赖到接口依赖给你看一个我非常喜欢的重构小案例。一开始的代码长这样public class PayService { private WeChatPay weChatPay new WeChatPay(); public void pay(int amount) { weChatPay.pay(amount); } }这个写法的问题很明显PayService直接new了一个具体的WeChatPay一旦要接入支付宝就得改PayService。改成接口依赖之后public interface Pay { void pay(int amount); } public class WeChatPay implements Pay { ... } public class PayService { private Pay pay; public PayService(Pay pay) { // 通过构造方法注入实现类 this.pay pay; } public void pay(int amount) { pay.pay(amount); } }此时PayService完全只认识Pay这个抽象不再关心具体是谁在干活。以后扩展支付宝、银联、国际卡都只是新增实现类的事儿PayService一行代码都不用动。这种重构带来的收益是立竿见影的也是面试中考“面向接口编程”意图时最常举的例子。5. 接口学习的坑与面试高频点复盘最后一部分集中处理初学者在接口这条路上最常栽的跟头以及面试里被反复追问的考点希望帮你少走一点弯路。5.1 五个高频错误与对应认知第一在接口里定义变量并试图修改。前面说过接口里的变量自动就是public static final常量一旦赋值不能修改。如果业务确实需要状态请用抽象类或普通类。第二实现类方法漏写public。接口方法是public abstract实现类覆盖时如果写了private编译器直接报错原因是访问权限不能缩小。第三误把默认方法当普通实现方法到处用。默认方法的定位是平滑演进和公共逻辑不是让你把接口写成大杂烩类。接口的核心仍是抽象契约。第四没搞清楚接口能否创建对象。接口不能直接new但可以声明接口类型的引用并指向实现类的对象也可以用匿名内部类或lambda表达式在代码里写出其实例。这一点在后面的函数式编程相关篇章里还会展开。第五把接口和抽象类画等号。默认方法让两者外表趋同但语义完全不同抽象类是类体系的骨架接口是能力的契约。多问一句“我设计的是‘是什么’还是‘能做什么’”选择就不容易出错。5.2 面试里围绕接口的几个经典提问面试中对接口的提问通常围着几个老问题打转思路可以参考为什么Java类不支持多继承但接口可以多实现——单继承避免菱形继承的歧义和状态混乱接口不保存状态只承诺行为多实现不会引发状态歧义。接口里的变量是什么修饰符——public static final三合一的答案必须脱口而出。Java 8接口有哪些新特性——默认方法、静态方法、函数式接口与lambda结合Java 9还加了私有方法。接口和抽象类如何选择——先看是不是“is-a”关系再看是否需要共享状态和构造函数最后看是否有多实现需求。如何理解“面向接口编程”——用“接口定义做什么实现类决定怎么做”来回答配合支付系统、DAO分层或策略模式举例。5.3 一点实操心得如果你现在正在学接口建议动手做一个小练习随便挑一个你平时用的业务场景写完一版基于具体类的代码然后用接口重构一版对比两者在“新增一个功能”时需要改动的文件数量。只有亲手经历过“什么代码都要跟着动”的痛才能真正理解接口降低耦合的价值。最后想到一个细节想分享接口命名。Java里接口的命名习惯是用形容词或者能力词比如Runnable、Comparable、Serializable偶尔也有名词型前缀I开头的风格比如IUserService。老代码里I开头不少见新代码更倾向用形容词风格但关键不是选哪种而是一个项目里要保持一致。命名统一这件事在接口这种抽象类型上体现尤其明显因为它会被大量实现和引用命名风格一旦混乱排查成本非常高。我在实际项目中体会最深的是接口在整个系统里像一套约定它约束了每块代码彼此之间的边界也让换实现、加扩展这件事变得不那么可怕。学到这里的你不妨在自己的代码里多留一个心眼遇到“这方法以后可能会变”的地方优先考虑用接口把变化隔离出来。这比任何语法技巧都值钱。 Java接口深入理解：从语法规则到面向接口编程实战
1. 接口是什么从USB插口到代码契约如果你用过电脑一定见过USB接口。这个接口本身不包含任何功能它只定义了一套尺寸和电气的规范任何一个厂商生产的U盘、手机、读卡器只要遵循这个规范接上去就能工作。Java里的接口也是这个逻辑——它定义了一套规则任何类只要声明实现了它就必须按这套规则办事。在Java面向对象的体系里接口是一个极其常见又容易被忽视的关键字。很多初学者在学到这里时觉得接口无非就是“把抽象类的抽象部分拎出来”这种理解不能说错但会把接口用窄了。接口真正的价值不在于语法本身多复杂而在于它提供了一种“约定优于实现”的组织方式让代码可以按能力来组合而不是按继承树来纵向绑定。这个系列前面聊过类、对象、继承和多态。你应该有印象Java的类只支持单继承一个类只能有一个父类。这个设计极大降低了对象模型的复杂度避免了多继承带来的菱形冲突问题但也让“复用能力”这件事变得有些局促——假设我有一个可以飞行的能力想让飞机类和超人角色类共享如果只能靠继承就得强行给它们找一个共同的父类这个父类往往非常牵强甚至会污染整个继承设计。接口的出现正是为了解决这类问题。它把“是什么”继承体系和“能做什么”能力清单分开了飞机是交通工具超人是角色它们都可以“飞”而“飞”这个能力用接口来表达就再合适不过。实现同一个接口的类可以来自完全不同的继承分支这打破了单继承的局限性也让代码的表达方式更灵活。1.1 接口强调“能做什么”而不是“是什么”这句话值得反复揣摩。抽象类和接口的区别核心就在这。当你在设计一个抽象类时你实际上是在定义“这一类事物的共同底座”。比如抽象类Animal里面有属性name、age有具体方法eat()有抽象方法move()它强调的是一类动物共有的特征和状态。而接口比如Flyable里面只写一个fly()方法它不关心谁在飞、怎么飞只表达一个事实实现这个接口的东西一定能飞。所以面向对象设计里有一句经典的口号面向接口编程而不是面向实现编程。依赖一个接口意味着你只关心对方能提供什么而不关心它内部是怎么实现的。这样未来换实现类、扩展新实现上游代码都不需要改动。1.2 接口是Java实现多态的另一条路径之前讲多态时你看到的多态通常是父类引用指向子类对象。接口同样可以做到类似的效果而且适用范围更宽。你可以声明一个接口类型的变量然后让它指向任何一个实现了这个接口的类的对象调用时执行的是具体实现类里的方法。这种通过接口实现的多态在日常开发中使用频率极高。例如一个支付系统你有微信支付、支付宝支付、银行卡支付三个类它们都实现同一个Payment接口业务代码只需要面向Payment接口来写完全不需要关心当前用户选的是哪种支付方式。当我们需要接入新的支付渠道时只需要新增一个实现类就够了原有的支付流程代码一行不用动。这种设计上的弹性就是接口存在的意义之一。2. 动手写第一个接口语法拆解与隐藏规则聊清楚了接口的定位我们来看语法。接口的定义用interface关键字比类简单很多但细节都在“隐藏规则”里。2.1 基本定义与实现看一个最简单的例子public interface Flyable { void fly(); }它定义了一个名为Flyable的接口里面有一个抽象方法fly()。注意在接口里写方法时即使你不加public abstract这两个修饰符也是默认存在的。换句话说接口里的抽象方法本质上就是public abstract的。一个类要实现这个接口用implements关键字public class Bird implements Flyable { Override public void fly() { System.out.println(鸟儿扇动翅膀飞行); } } public class Plane extends Machine implements Flyable { Override public void fly() { System.out.println(飞机喷气推进飞行); } }可以看到Plane继承了Machine类同时又实现了Flyable接口。类和接口的组合让能力叠加变得很自然这也是接口最核心的用法。2.2 必须实现所有抽象方法吗——是的除非你是抽象类一个普通类实现接口后必须实现接口里的所有抽象方法否则编译器会报错。这里有两个例外第一如果实现类也是抽象类它可以选择只实现一部分方法把剩下的继续声明为抽象方法交给它的子类完成。第二如果实现的是Java 8之后带默认方法的接口后面会细说默认方法不需要实现。所以编译期的规则很简单一个具体类收到接口的“契约”就必须全盘接受。漏写一个方法IDE里就会出现红色波浪线这是一个很常见的初学者报错。2.3 接口里的“隐形修饰符”这是我每次讲接口都要单独强调的地方。接口里的成员变量不管写不写修饰符实际上都是public static final的。也就是说接口里没有真正的“实例变量”只有常量这个常量属于接口本身不随实现类对象变化实现类可以引用它但不能重新赋值。看代码public interface SpeedLimit { int MAX_SPEED 120; // 实际等于 public static final int MAX_SPEED 120; } public class Car implements SpeedLimit { public void show() { // MAX_SPEED是常量属于接口所有 System.out.println(限速 MAX_SPEED); } }反过来接口里的普通方法默认都带public abstract。这也意味着你在实现接口方法时不能把方法的访问权限缩小比如不能写成private void fly()因为实现方法必须满足父级方法的可见性约定这是Java的规则。2.4 接口可以继承接口一个类可以同时实现多个接口刚才说过类只能单继承但接口不受这个限制。一个接口可以通过extends继承另一个接口获得它所有的抽象方法声明public interface AnimalAction extends Eat, Moveable { void sleep(); }而一个类可以同时 implements 多个接口这是Java用来弥补单继承能力不足的重要手段public class Robot implements Flyable, Chargeable, Recordable { // 需要实现三个接口里所有的抽象方法 }多实现的组合能力正是很多框架设计中依赖接口让对象扮演多重角色的基础。设计模式里的适配器、装饰器都大量依赖接口的这种多组合特性。2.5 空接口也是一种设计接口里可以一个方法都没有比如java.io.Serializable、Cloneable就是典型的空接口标记接口。它们表面上看没有任何要求实际上是在给对象打标签告诉虚拟机或工具类“这个类的对象可以被序列化”或“可以被克隆”。这是接口一个非常有意思的亚种面试里也偶尔会问到。3. Java 8之后的接口新能力默认方法、静态方法与私有方法如果你在用的Java版本是8或更高那接口的能力远不止“纯抽象”这么简单。Java 8之后接口家族多了三个重要成员这也是初学者容易把接口和抽象类搞混的根源之一。3.1 默认方法default method接口升级不再折腾所有实现类在Java 8之前接口几乎对所有方法一视同仁都必须被实现。这带来一个很现实的问题——假设你的接口已经被几十个类实现了某天你需要往接口里加一个新方法那么所有实现类都必须同步修改否则编译报错。对于框架开发者来说这种“接口演进”的代价极其可怕。默认方法解决了这个问题。用default关键字修饰的方法可以自带实现体实现类可以直接用也可以覆盖它完全不会影响其他已有实现类。public interface Payment { void pay(double amount); // 默认方法所有支付方式都能共用这套校验逻辑也可以各自覆盖 default boolean checkAmount(double amount) { return amount 0 amount 100000; } }这样一来新的Implementer类的实现负担大幅减轻同时老代码也能无痛升级。多个接口同时提供同签名默认方法的时候就会触发冲突问题。Java给出的规则是优先覆盖冲突出具体来说分三步——第一步看实现类自己有没有覆盖这个方法有就直接用第二步看父子接口之间的优先级子接口的默认方法优先于父接口第三步如果多个互不相关的接口都有同名默认方法实现类必须自己重写这个方法否则编译报错。3.2 静态方法接口里也能有工具方法Java 8同时允许在接口里定义static方法static方法属于接口本身不参与继承也不能通过实现类对象调用。它通常用来放一些和这个接口概念密切相关的工具方法。public interface MathOperations { static double toRadians(double degrees) { return degrees * Math.PI / 180.0; } }调用时只能写MathOperations.toRadians(180)这个和类的静态方法很类似。3.3 私有方法Java 9默认方法之间的代码复用Java 9之后接口还允许定义private方法主要用途是抽取出默认方法之间重复的公共逻辑。这种private方法只能被接口内部的默认方法或静态方法调用对外不可见从而实现了“内部复用而不暴露”的效果。3.4 接口与抽象类现在什么时候该用谁默认方法出现后接口和抽象类看起来都有“具体实现”了边界确实模糊了一些但定位依然清晰对比维度接口抽象类关键词interface / implementsabstract class / extends继承数量一个类可实现多个接口一个类只能继承一个抽象类成员变量只能是常量public static final可以有实例变量、成员变量构造函数没有构造函数有构造函数方法形态抽象方法、默认方法、静态方法、私有方法抽象方法、具体方法、静态方法设计语义强调“能做什么”能力契约强调“是什么”类型根基演进成本默认方法可以平滑扩展加方法需要谨慎评估所有子类我个人的经验是优先考虑接口只有当需要共享状态、共用成员变量、提供模板骨架时才考虑抽象类。JDK本身很多设计也是这样做的比如List接口加了一堆default方法而AbstractList抽象类则提供了默认实现骨架。4. 实战面向接口编程的三个典型场景语法学完得看它在真实项目里怎么发挥作用。我在实际开发里最常见到接口承载三大类职责分开说。4.1 DAO层接口让业务代码与数据源解耦在一个业务系统里数据访问层DAO几乎一定会先用接口定义操作再提供具体实现。比如订单模块你先定义OrderDao接口里面写上insert、findById、updateStatus这些方法然后MySQL的订单实现类去实现它。这样业务层依赖的是OrderDao接口而不是某个具体的数据库实现类。以后如果要从MySQL迁到PostgreSQL或者换一个ORM框架只需要新增一个实现类业务代码甚至不需要感知到变化。这种把“变化点”隔离在接口后面的做法是大型项目能持续演进的基石。4.2 策略模式算法随时可替换策略模式是最容易理解接口价值的场景之一。假设你的系统支持多种运费计算规则普通快递、冷链、同城速递价格算法各不相同。如果不做设计你大概率会写出一个巨型方法里面塞满if else。每次增加新配送方式都要改动这段核心逻辑风险极高。用接口重构的思路是这样定义ShippingStrategy接口里面一个方法calculate(Order order)每种配送方式写一个实现类调用方只需要持有接口引用在运行时根据配置或用户选择塞进来一个具体实现。加新策略时添加新类即可原有代码不动完美符合开闭原则。4.3 回调接口框架把控制权交还给业务方回调是接口的另一大应用场景。框架比如定时任务框架、消息队列消费者、GUI事件系统本身不知道你的业务逻辑它只能按照预定流程执行然后在合适的时机调用你提供的接口方法。这些方法就是回调。Spring里最常见的ApplicationContextAware、BeanNameAware都是这个套路定时任务框架里定义Job接口你实现execute方法框架在触发时间点调用它。通过接口回调框架和业务方实现了松耦合谁都不用强依赖谁。4.4 一个小型重构案例从具体类依赖到接口依赖给你看一个我非常喜欢的重构小案例。一开始的代码长这样public class PayService { private WeChatPay weChatPay new WeChatPay(); public void pay(int amount) { weChatPay.pay(amount); } }这个写法的问题很明显PayService直接new了一个具体的WeChatPay一旦要接入支付宝就得改PayService。改成接口依赖之后public interface Pay { void pay(int amount); } public class WeChatPay implements Pay { ... } public class PayService { private Pay pay; public PayService(Pay pay) { // 通过构造方法注入实现类 this.pay pay; } public void pay(int amount) { pay.pay(amount); } }此时PayService完全只认识Pay这个抽象不再关心具体是谁在干活。以后扩展支付宝、银联、国际卡都只是新增实现类的事儿PayService一行代码都不用动。这种重构带来的收益是立竿见影的也是面试中考“面向接口编程”意图时最常举的例子。5. 接口学习的坑与面试高频点复盘最后一部分集中处理初学者在接口这条路上最常栽的跟头以及面试里被反复追问的考点希望帮你少走一点弯路。5.1 五个高频错误与对应认知第一在接口里定义变量并试图修改。前面说过接口里的变量自动就是public static final常量一旦赋值不能修改。如果业务确实需要状态请用抽象类或普通类。第二实现类方法漏写public。接口方法是public abstract实现类覆盖时如果写了private编译器直接报错原因是访问权限不能缩小。第三误把默认方法当普通实现方法到处用。默认方法的定位是平滑演进和公共逻辑不是让你把接口写成大杂烩类。接口的核心仍是抽象契约。第四没搞清楚接口能否创建对象。接口不能直接new但可以声明接口类型的引用并指向实现类的对象也可以用匿名内部类或lambda表达式在代码里写出其实例。这一点在后面的函数式编程相关篇章里还会展开。第五把接口和抽象类画等号。默认方法让两者外表趋同但语义完全不同抽象类是类体系的骨架接口是能力的契约。多问一句“我设计的是‘是什么’还是‘能做什么’”选择就不容易出错。5.2 面试里围绕接口的几个经典提问面试中对接口的提问通常围着几个老问题打转思路可以参考为什么Java类不支持多继承但接口可以多实现——单继承避免菱形继承的歧义和状态混乱接口不保存状态只承诺行为多实现不会引发状态歧义。接口里的变量是什么修饰符——public static final三合一的答案必须脱口而出。Java 8接口有哪些新特性——默认方法、静态方法、函数式接口与lambda结合Java 9还加了私有方法。接口和抽象类如何选择——先看是不是“is-a”关系再看是否需要共享状态和构造函数最后看是否有多实现需求。如何理解“面向接口编程”——用“接口定义做什么实现类决定怎么做”来回答配合支付系统、DAO分层或策略模式举例。5.3 一点实操心得如果你现在正在学接口建议动手做一个小练习随便挑一个你平时用的业务场景写完一版基于具体类的代码然后用接口重构一版对比两者在“新增一个功能”时需要改动的文件数量。只有亲手经历过“什么代码都要跟着动”的痛才能真正理解接口降低耦合的价值。最后想到一个细节想分享接口命名。Java里接口的命名习惯是用形容词或者能力词比如Runnable、Comparable、Serializable偶尔也有名词型前缀I开头的风格比如IUserService。老代码里I开头不少见新代码更倾向用形容词风格但关键不是选哪种而是一个项目里要保持一致。命名统一这件事在接口这种抽象类型上体现尤其明显因为它会被大量实现和引用命名风格一旦混乱排查成本非常高。我在实际项目中体会最深的是接口在整个系统里像一套约定它约束了每块代码彼此之间的边界也让换实现、加扩展这件事变得不那么可怕。学到这里的你不妨在自己的代码里多留一个心眼遇到“这方法以后可能会变”的地方优先考虑用接口把变化隔离出来。这比任何语法技巧都值钱。