抽象类与接口的多态实现：从原理到实战

刚开始带项目组里几个新转Java的同事时，我发现大家最绕不过去的坎，往往是抽象类、接口、多态这三个词。网上资料倒是一搜一大把，可翻来覆去就是“抽象类可以有构造方法，接口不能有成员变量”这类口诀式对比，背得滚瓜烂熟，真到写代码时却不知道怎么选，看别人的框架代码也看不明白为什么要绕这么一大圈。

这次我就把标题里的“抽象类与接口中的多态实现”这件事彻底讲透。先说明动机：这三个概念不是孤立的语法点，它们组合在一起，才是Java面向对象设计的真正核心。文章里我会结合一个完整的消息推送案例，从抽象类和接口的设计意图出发，讲清楚多态在底层是怎么发生的，再到实际项目里应该怎么取舍，最后把面试里常考的那些“区别题”和实战中容易踩的坑一起梳理一遍。不管你是正在准备面试，还是写了两年代码但始终对“面向对象”感觉隔了一层，这篇文章应该都能帮你把线头理顺。

1. 先把抽象类和接口的设计意图讲明白

1.1 抽象类：它回答的是“你是什么”

抽象类用 abstract 关键字修饰，核心特征是“不能被实例化”，但它可以有构造方法、成员变量、普通方法、抽象方法，所有普通类的语法它基本都支持。为什么会这样设计？因为抽象类在语义上代表的是一个“不完整的类型”，它还没有具体到可以被直接 new 出来的程度。

说个生活化的例子。你到店里说“我要买一台手机”，店员会问你“买哪款？”——因为“手机”这个概念太抽象了，它不确定品牌、型号、配置，但它一定有屏幕、电池、操作系统这些共同属性。抽象类在这里扮演的就是“手机”这个角色：它把子类共有的字段和行为沉淀下来，再留下一两个未实现的方法让子类去填充。比如“开机”这个动作，所有手机都会开机，但具体到某个品牌可能开机流程不太一样，抽象类就可以把“开机”声明成抽象方法，强制子类自己实现。

所以抽象类强调的是一个 is-a 关系，子类在逻辑上必须“是一种”父类。它最大的价值是代码复用，把公共状态和行为上提到父类里，避免每个子类重复写一遍相同的逻辑。

1.2 接口：它回答的是“你能做什么”

接口用 interface 关键字定义。在Java 8之前，接口里只能有抽象方法和常量（public static final），没有构造方法，不能有具体实现。Java 8开始可以写 default 方法和 static 方法，Java 9甚至允许 private 方法了。这些语法层面的变化后面会细说，但接口的核心语义始终没变：它是一份能力契约。

再举个例子。考驾照的时候，你拿到的C1驾照就是一份“我能开手动挡汽车”的能力凭证。至于你开的是大众还是丰田、是轿车还是SUV，驾照不关心，只要你有这个能力，符合操作规范，就可以驾驶对应车型。接口就是这份驾照：它约定了“能做什么”（比如 drive()），但完全不关心实现者是谁、怎么实现。

所以接口强调的是一种 can-do 关系，实现类不需要和接口有“同类”的归属关系，只需要具备约定的能力即可。这意味着一个类可以同时实现多个接口——既能“开汽车”，又能“开挖掘机”，还能“开飞机”，这在语义上完全说得通。

1.3 一张表带你对比核心语法差异

这张表基本覆盖了面试里“接口和抽象类的区别”的标准答案。不过面试光背这张表是不够的，下面我会把每个细节背后的“为什么”也拆开，尤其是它和多态怎么配合，这才是真正的重点。

2. 多态的底层机制——为什么父类引用能调子类方法

2.1 编译看左边，运行看右边

多态（Polymorphism）在Java中的经典定义是：同一操作作用于不同的对象，可以产生不同的执行结果。很多人背得出这句话，但遇到实际代码还是容易懵。比如这段代码：

java复制Animal animal = new Dog();
animal.sound(); // 输出“汪汪汪”

声明类型是 Animal，实际对象是 Dog，调用 sound() 时执行的是 Dog 里重写的方法。这背后的机制叫动态绑定（Dynamic Binding），也叫运行时多态。JVM在执行 invokevirtual 指令时，会根据实际对象的类型，在方法表里找到对应的方法入口，而不是直接看引用变量的声明类型。

2.2 动态绑定和静态绑定的区别

Java的方法调用其实有两类绑定方式：

1. 静态绑定：编译期就能确定调用哪个方法，典型场景是重载（Overload）。比如 print(int x) 和 print(String s)，参数类型不同，编译器在编译时就能决定调哪个。
2. 动态绑定：编译期只能确定方法签名，真正的方法实现要运行时根据对象的实际类型去查，典型场景是重写（Override）。

这里补充一个重要概念：重载不是多态。虽然有些教材把重载叫“编译期多态”，但在实战和面试里，我们讨论的多态默认指运行期多态，也就是基于重写和动态绑定的那套机制。如果你在简历上写着“熟悉Java多态”，面试官追问“重载算不算多态”，最好先把这个定义边界说清楚。

2.3 多态发生的三个必要条件

基于上面的分析，运行期多态需要满足以下条件：

• 必须有继承关系（类与类之间）或者实现关系（类与接口之间）。
• 子类/实现类必须重写父类/接口的方法。
• 父类引用/接口引用指向子类对象/实现类对象。

这三个条件缺一不可。不要小看这些基础，我帮同事排查过一个线上问题，最后发现就是有人在一个类里写了同签名的方法但没加 @Override，结果方法名拼错了一个字母，导致调用的是父类方法，整个流程都走错了。这种情况用 @Override 注解就能立刻暴露出来，所以我在代码规范里一直强调：重写方法必须加 @Override。

2.4 一次完整的方法查找过程

java复制public abstract class Animal {
    public abstract void sound();
}

public class Dog extends Animal {
    @Override
    public void sound() {
        System.out.println("汪汪汪");
    }
}

public class Cat extends Animal {
    @Override
    public void sound() {
        System.out.println("喵喵喵");
    }
}

public static void main(String[] args) {
    Animal a1 = new Dog();
    Animal a2 = new Cat();
    a1.sound();
    a2.sound();
}

当执行 a1.sound() 时，JVM会先检查 Animal 的声明类型，确认 sound() 方法存在且可访问，然后在运行时去 a1 实际指向的 Dog 对象中查找重写过的方法并执行。这就是“编译看左边，运行看右边”的完整含义。

这个机制的价值在于：写代码的人只需要面向抽象编程，不需要关心具体实现类是什么。后面这个思想会反复出现，它就是多态和抽象类、接口组合的底层原因。

3. 抽象类与接口在多态中的分工，到底该怎么选

3.1 关键词是“复用”还是“契约”

面试高频率提问“什么时候用接口，什么时候用抽象类”，这个问题没有一个万能答案，但我可以给一个非常实用的判断标准：

当你需要把公共代码沉淀到父类，让子类复用字段和逻辑时，用抽象类；当你需要定义能力边界，让各不相干的类都能接入你的系统时，用接口。

举个例子。一个电商系统里有微信支付、支付宝支付、银联支付三种渠道。分析它们的共性：都有商户号、都有支付金额、都需要校验签名、都需要记录流水。这时候做一个 AbstractPayChannel 抽象类，把这些公共逻辑沉淀下来，三个支付渠道分别继承它，就能省掉大量重复代码。同时，我们单独定义一个 Payable 接口，里面就一个方法 PayResult pay(PayRequest request)，表示“只要能调这个接口，你就能在系统里作为支付方式被使用”。这三者的关系是：

java复制public interface Payable {
    PayResult pay(PayRequest request);
}

public abstract class AbstractPayChannel implements Payable {
    protected String merchantId;
    protected String signKey;

    public AbstractPayChannel(String merchantId, String signKey) {
        this.merchantId = merchantId;
        this.signKey = signKey;
    }

    protected boolean verifySign(Map<String, String> params) {
        // 公共签名校验逻辑
        return true;
    }

    protected void savePayLog(PayRequest request) {
        // 公共流水记录逻辑
    }

    @Override
    public abstract PayResult pay(PayRequest request);
}

public class WechatPayChannel extends AbstractPayChannel {
    public WechatPayChannel(String merchantId, String signKey) {
        super(merchantId, signKey);
    }

    @Override
    public PayResult pay(PayRequest request) {
        // 先做公共的签名校验与流水记录
        verifySign(request.getParams());
        savePayLog(request);
        // 再执行微信特有的下单逻辑
        return doWechatPay(request);
    }
}

这个场景里，抽象类和接口不是二选一，而是组合使用，这也是实际项目中最常见的设计方式。接口保证了系统可扩展（以后接一个新的支付渠道，只需要实现 Payable），抽象类保证了实现成本低（公共代码已经准备好了）。

3.2 经典决策清单：完事具备，只差这张表

这张表可以当作决策清单使用。需要强调的是：实际情况往往是接口和抽象类一起用，就像上面的支付例子一样。很多初级开发者以为二选一就结束了，其实这是误区。

3.3 Java 8之后的接口还能这么用？影响选型的关键变化

Java 8给接口加了 default 方法和 static 方法，这让接口“看起来”越来越像抽象类。这里有几个关键的实践要点：

• default 方法的意义在于平滑演进。一个接口如果已经被几百个类实现，后来想加一个新的方法，如果直接加抽象方法，所有实现类都要改，这在业务代码里就是灾难。加一个 default 方法，实现类可以选择性重写，接口自身提供兜底实现。典型例子就是 List 接口的 sort、stream 方法，JDK自己就是靠这种方式演进的。

• static 方法适合放一些与接口相关的工具方法。比如 Comparator.comparing、Collection 接口里的静态工厂方法等，它们不需要实例对象就能调用，天然和接口逻辑绑定。

• 接口里的 private 方法（Java 9+）是给 default 方法提供私有工具逻辑的，目的是把重复代码收拢到私有方法里，又不对外暴露。

那是不是说Java 8之后接口可以完全替代抽象类了？并不是。接口依然不能有实例字段（除非是常量），也不能有构造方法，所以在需要保存状态、需要构造器初始化的场景里，抽象类依然是唯一解。而且从语义维护角度讲，抽象类里的 protected 方法和字段可以充分开放给子类访问，接口则天然建议“对外只暴露公共契约”，这两者的设计出发点差别很大。

4. 实操：一个从零搭建的消息推送系统，把多态彻底用起来

讲了这么多理论，不落地实操等于白说。下面我带大家做一个消息推送系统，用抽象类 + 接口 + 多态的组合，把整个过程拆开走一遍。这个案例是我在真实项目中简化出来的，贴近实际开发，不是那种为了演示而演示的玩具代码。

4.1 需求拆解：三种渠道，公共逻辑与个性逻辑

假设系统需要支持三种消息发送渠道：短信（SMS）、邮件（Email）、站内推送（Push）。所有消息都有这些公共要素：收件人、消息标题、消息内容、发送时间、模板ID。三种渠道各自的发送方式完全不同，但发送前都要做“模板渲染”和“发送日志记录”这两个公共动作。

按照前面讲的选型逻辑来设计：

• 用抽象类 AbstractMessage 承载公共字段和公共方法，比如 renderContent() 里做公共的模板变量替换，saveLog() 里记录日志，再留一个 send() 抽象方法。
• 用接口 MessageSender 定义“能发送消息”的能力契约，接口里只有一个 boolean send(AbstractMessage message) 方法。
• 具体渠道各自继承抽象类并实现接口。

4.2 第一步：定义抽象消息类

java复制public abstract class AbstractMessage {
    protected String receiver;
    protected String title;
    protected String content;
    protected long templateId;

    public AbstractMessage(String receiver, long templateId) {
        this.receiver = receiver;
        this.templateId = templateId;
    }

    // 抽象方法：每个渠道的发送逻辑完全不同，强制子类实现
    public abstract boolean send();

    // 公共方法：所有渠道的模板渲染逻辑一致
    protected String renderContent(Map<String, String> params) {
        // 实际项目中这里会去查模板配置，再把参数替换进模板
        String template = loadTemplateFromCache(templateId);
        for (Map.Entry<String, String> entry : params.entrySet()) {
            template = template.replace("${" + entry.getKey() + "}", entry.getValue());
        }
        return template;
    }

    // 公共方法：保存发送日志
    protected void saveLog(String channel) {
        System.out.println("保存发送日志: channel=" + channel + ", receiver=" + receiver);
    }

    private String loadTemplateFromCache(long templateId) {
        // 模拟从缓存加载模板
        return "您好 ${name}，您的验证码是 ${code}";
    }
}

这里用到的模板方法思想是抽象类最典型的用法：骨架（公共字段 + 公共方法 + 抽象方法）已经定义好，子类只需要关心自己特有的部分。读者可以注意一下 renderContent 里的模板替换逻辑，这就是“公共逻辑下沉到父类”的常见示例。

4.3 第二步：定义消息发送接口

java复制public interface MessageSender {
    boolean send(AbstractMessage message);
}

有人可能会问：抽象类里已经有 send() 抽象方法了，为什么还要一个 MessageSender 接口？这个问题问得非常好。原因是职责不同：

• AbstractMessage 里的 send() 描述的是“消息这个对象能把自己发送出去”，这有点把发送行为绑定在数据对象上。
• 而 MessageSender 接口描述的是“某类发送器具备发送能力”，它是独立于消息对象的处理者，更贴近现实世界的“短信服务商”、“邮件服务器”等概念。

在真实项目的设计里，我更推荐把发送行为放到 Sender 类型上，因为这样可以轻松实现“同一渠道的不同策略”（比如同一个短信渠道，有不同的供应商方案，只需实现同一个接口），数据对象保持纯净，更符合单一职责原则。

4.4 第三步：具体消息子类与具体发送器实现

java复制public class SmsMessage extends AbstractMessage {
    public SmsMessage(String receiver, long templateId) {
        super(receiver, templateId);
    }

    @Override
    public boolean send() {
        saveLog("SMS");
        System.out.println("发送短信给: " + receiver);
        return true;
    }
}

public class EmailMessage extends AbstractMessage {
    private String cc;

    public EmailMessage(String receiver, long templateId, String cc) {
        super(receiver, templateId);
        this.cc = cc;
    }

    @Override
    public boolean send() {
        saveLog("EMAIL");
        System.out.println("发送邮件给: " + receiver + ", 抄送: " + cc);
        return true;
    }
}

public class PushMessage extends AbstractMessage {
    public PushMessage(String receiver, long templateId) {
        super(receiver, templateId);
    }

    @Override
    public boolean send() {
        saveLog("PUSH");
        System.out.println("发送站内推送给: " + receiver);
        return true;
    }
}

然后定义对应的发送器：

java复制public class SmsSender implements MessageSender {
    @Override
    public boolean send(AbstractMessage message) {
        // 短信渠道的特殊处理：需要调用短信网关，此处省略
        return message.send();
    }
}

public class EmailSender implements MessageSender {
    @Override
    public boolean send(AbstractMessage message) {
        // 邮件渠道特殊处理：设置邮件服务器、附件等
        return message.send();
    }
}

public class PushSender implements MessageSender {
    @Override
    public boolean send(AbstractMessage message) {
        // 推送渠道特殊处理：连接长连接网关
        return message.send();
    }
}

4.5 第四步：用多态统一调用入口

java复制public class MessageService {
    // 用一个 Map 缓存所有 Sender，key 是渠道名
    private final Map<String, MessageSender> senderMap = new HashMap<>();

    public MessageService() {
        senderMap.put("SMS", new SmsSender());
        senderMap.put("EMAIL", new EmailSender());
        senderMap.put("PUSH", new PushSender());
    }

    public void sendMessage(String channel, AbstractMessage message) {
        MessageSender sender = senderMap.get(channel);
        if (sender == null) {
            throw new IllegalArgumentException("不支持的渠道: " + channel);
        }
        // 这里就是多态的核心调用：同一接口引用，运行时执行不同的实现
        boolean success = sender.send(message);
        System.out.println("发送结果: " + success);
    }

    public static void main(String[] args) {
        MessageService service = new MessageService();
        service.sendMessage("SMS", new SmsMessage("13800138000", 1001L));
        service.sendMessage("EMAIL", new EmailMessage("user@example.com", 1002L, "admin@example.com"));
        service.sendMessage("PUSH", new PushMessage("user_001", 1003L));
    }
}

执行这段代码，你会在控制台看到三种渠道各自不同的发送日志和结果。这就是最直观的多态体现：senderMap.get(channel) 拿到的类型声明是 MessageSender 接口，但运行时可能是 SmsSender、EmailSender 或 PushSender。sender.send(message) 这一行代码，根据实际对象类型走了完全不同的实现。以后要增加一个“站内信”渠道，只需要写一个 InboxMessage 和一个 InboxSender，然后往 senderMap 里加一行注册代码，其他逻辑完全不用动——这种可扩展性正是面向对象设计追求的核心价值。

4.6 结合Spring框架实战：自动注入多实现

真实项目里很少会像上面那样手动维护 senderMap。如果项目用的是Spring Boot，惯用做法是让Spring把某个接口的所有实现类自动注入成一个 List：

java复制@Service
public class MessageService {
    private final Map<String, MessageSender> senderMap;

    // Spring 会把所有 MessageSender 实现类注入到这个 List
    public MessageService(List<MessageSender> senders) {
        senderMap = new HashMap<>();
        for (MessageSender sender : senders) {
            senderMap.put(sender.channelName(), sender);
        }
    }

    public void sendMessage(String channel, AbstractMessage message) {
        MessageSender sender = senderMap.get(channel);
        // ...
    }
}

这个模式在源码里非常常见，比如Spring Security里对各种 Configurer 的处理、数据源路由对不同数据库方言的处理等，都是“接口 + 多实现 + 多态分发”的经典套路。看懂了上面的消息推送案例，再去看框架源码会轻松很多。

5. 面试高频题与实战中容易踩的坑

5.1 先把这些高频题的标准回答理一遍

面试的时候，随手抽一道“Java基础”相关的题，绕不开这几个。我按实际考察点整理一下：

Q1：接口和抽象类的区别？

这道题考察的是基础概念掌握程度。稳妥的回答框架是：先说语法差异（构造方法、成员变量、方法实现、单继承/多实现，参考前文表格），再说设计语义差异（is-a vs can-do、代码复用 vs 能力契约），最后补充一个实践层面的观点：实际项目中两者常组合使用，抽象类做代码复用底座，接口做系统能力边界。

Q2：什么时候用抽象类，什么时候用接口？

这道题考察的是设计能力，比Q1更进一层。回答时要避免只背概念，最好结合具体业务场景。比如支付渠道那个例子就是我自己常用的回答：多个渠道有公共字段和公共逻辑时用抽象类；系统需要定义扩展点、让不同模块互相解耦时用接口。

Q3：抽象类和普通类的区别？

这道题看起来简单，其实是考察对“抽象”这个概念的理解深度。可以从三个层面回答：抽象类不能被实例化；抽象类可以有抽象方法；抽象类的意义在于定义模板和框架，普通类是可直接使用的完整实现。再补充一点：抽象类构造方法的执行时机——子类实例化时，父类构造方法会先执行，抽象方法在构造方法里被调用时会触发动态绑定，访问的是子类实现——但这里有个大坑，后面第5.3节会专门说。

Q4：重载和重写的区别？

尽管这道题看着基础，实际上很多人都答不完整。标准答法：重载是同一个类里方法名相同、参数列表不同的编译期多态；重写是子类对父类方法的重新实现，方法签名必须一致，运行期多态。重写需要注意访问权限不能降低、返回类型可以协变、throws 异常范围不能扩大（Java 7之前）等细节。

Q5：Java为什么不支持多重继承，但可以实现多个接口？

这道题本质上是考接口和抽象类在“继承机制”上的区别。回答要点：多重继承会带来菱形继承问题——如果两个父类有相同签名的方法，子类该调用谁的？Java选择用单继承 + 多接口 + 默认方法（Java 8）来规避这个问题。默认方法虽然带来了类似多重继承的效果，但同样会出现菱形冲突，所以Java规定，如果两个接口有同签名默认方法，实现类必须显式重写该方法。

5.2 最容易翻车的三个实战坑

面试题背得好，不代表代码写得好。下面这几个坑是我和同事在真实项目里踩过的，每一个都“血泪教训”。

坑一：构造方法里的动态绑定。

看这段代码：

java复制public abstract class Parent {
    public Parent() {
        this.init(); // 抽象方法，运行时会调用子类实现
    }

    protected abstract void init();
}

public class Child extends Parent {
    private String name = "child";

    public Child() {
        super();
        System.out.println("Child构造完成");
    }

    @Override
    protected void init() {
        System.out.println("name = " + name); // 输出 null！
    }
}

运行时输出的是 name = null。原因在于：子类构造方法执行时，先调用 super()，此时子类字段还没有完成初始化（name = "child" 这个初始化动作在 super() 之后才会执行），但动态绑定已经触发，init() 里访问的是还没初始化的字段，自然就是 null。这就是为什么抽象类在构造方法里不允许调用自己的抽象方法——很多编程规范和静态检查工具会直接报警。

坑二：接口里的常量被实现类“篡改”。

接口里的变量默认是 public static final，所以从语法上不允许修改。但有一种常见误用：实现类里定义一个同名的成员变量，会导致“变量遮蔽”。

java复制public interface Payable {
    String CHANNEL = "default";
}

public class WechatPay implements Payable {
    private String CHANNEL = "wechat"; // 这其实是一个新变量，不是重写接口常量

    public void print() {
        System.out.println(CHANNEL); // 输出 wechat
        System.out.println(Payable.CHANNEL); // 输出 default
    }
}

这种代码在代码评审里很容易引起误解，规范起见接口常量一般命名全大写，成员变量遵循驼峰命名，两者不要重名。

坑三：接口 default 方法的菱形冲突。

如果两个接口里都有相同签名的 default 方法，实现类必须重写它，否则编译报错。

java复制public interface A {
    default void hello() {
        System.out.println("A.hello");
    }
}

public interface B {
    default void hello() {
        System.out.println("B.hello");
    }
}

public class C implements A, B {
    // 必须重写，否则编译失败
    @Override
    public void hello() {
        System.out.println("C.hello");
    }
}

这个机制很多人面试时知道，但实际编码时容易因为“两个接口恰好有同名字段或方法”而踩编译错误。尤其是引入第三方库的接口时，自己项目里的接口和库接口出现同名 default 方法，排查起来很麻烦，我在项目里就遇到过两次。应对措施是：自己定义的接口尽量起有辨识度的方法名，避免使用 do、run、send 这类过于通用的词。

5.3 为什么“八股文答案”过不了真正的大厂面试

现在网上流行“八股文”这个词，很多面试者把接口和抽象类的区别背得滚瓜烂熟，但面试官随便换个问法就露馅。常见追问方式有：

• 你刚才说接口不能有构造方法，那 List 接口里为什么没有构造方法，而 ArrayList 有？能不能在接口里用工厂方法代替构造方法？
• 抽象类里的普通方法能不能被重写？如果能，重写之后多态还成立吗？
• 抽象类能不能实现一个接口？如果能，抽象类可以不实现全部接口方法吗？
• default 方法的加入是不是让“接口与抽象类区别”这个问题的答案变了？变化在哪里？
• 换一个场景：Spring 事务代理是基于接口还是基于类？为什么 JDK 动态代理要求实现接口，CGLIB 不需要？

这些问题的本质是考察“你究竟是背了概念，还是真正理解了面向对象设计”。建议读者在准备面试时，不仅要会答“是什么”，更要会答“为什么这么设计”“如果换一种设计会有什么问题”。多读一下 ArrayList、HashMap、ThreadPoolExecutor 这些JDK源码里对接口和抽象类的运用，比死记硬背一百道题都管用。

6. 一些实用扩展：枚举、函数式接口与多态的配合

6.1 枚举里也可以谈多态？

很多人没注意到，Java枚举（enum）其实可以声明抽象方法，并且每个枚举常量可以单独实现。这在行为多态的落地里非常好用：

java复制public enum PayStrategy {
    WECHAT {
        @Override
        public void pay() {
            System.out.println("微信支付");
        }
    },
    ALIPAY {
        @Override
        public void pay() {
            System.out.println("支付宝支付");
        }
    },
    UNION {
        @Override
        public void pay() {
            System.out.println("银联支付");
        }
    };

    public abstract void pay();
}

这样写的好处是：把支付行为拆到了每个枚举常量里，调用方只需要 PayStrategy.WECHAT.pay()，这就是一种基于枚举的“策略模式变体”。它结合了枚举的天然单例性质和抽象方法的多态能力，在很多配置驱动场景里非常实用。不过要注意：如果枚举常量特别多，或者行为逻辑特别复杂，这种写法会让枚举类变得臃肿，更适合逻辑简单的场景。

6.2 函数式接口让多态的写法更轻量

Java 8 引入的 @FunctionalInterface 接口（比如 Function、Consumer、Predicate），本质上还是接口，只不过它只允许一个抽象方法，因此可以被Lambda表达式直接实现。这可以看作“接口多态”的快捷方式——你不用专门写实现类了，直接传入一个Lambda表达式作为行为参数：

java复制public class MessageProcessor {
    public void process(AbstractMessage message, Function<AbstractMessage, Boolean> handler) {
        boolean result = handler.apply(message);
        System.out.println("处理结果: " + result);
    }
}

processor.process(smsMessage, msg -> {
    System.out.println("自定义短信处理逻辑");
    return true;
});

这里 Function<AbstractMessage, Boolean> 就是一个函数式接口，Lambda表达式隐式实现了它的抽象方法。这正是多态的另一种表现形态：把“可变行为”作为参数传入，调用方决定具体逻辑，框架只负责编排。理解了这层，再看 .map().filter().collect() 这类流式操作就豁然开朗了。

6.3 项目里的设计约束：接口爆炸与抽象类过深的权衡

在实际项目里，最容易出现的两个极端是：接口滥用和抽象类层级过深。

接口滥用表现在：一上来就给每个Service都定义一个接口，哪怕这个Service只有一个实现类。代码结构显得很“规范”，但实际上是空转，增加了解读成本。我个人的判断标准是：如果这个类未来至少有95%的可能性会出现第二种实现，再定义接口；否则先写类，等有需要再提取。当然，如果团队约定“所有Service必须面向接口”，那也要遵守团队的规矩。

抽象类层级过深表现在：抽象类继承抽象类再继承抽象类，三层以上就很难读了——每次追踪一个方法的来源都要往父类跳好几层，很影响心情。遇到这种情况，我更倾向于用组合替代继承：把公共逻辑拆成独立的组件类，通过接口暴露能力，再用组合的方式让子类调用。这是面向对象设计里“组合优于继承”的典型应用。

7. 最后的实操心得

走到这一步，抽象类、接口、多态这三者应该已经在你的知识体系里串起来了。我个人实际操作下来的体会是：不要试图用“某个语法特性背下来”去解决设计问题，真正的设计判断永远基于两个问题——这段代码需不需要复用？这个系统的能力边界在哪里？想清楚了这两个问题，抽象类还是接口的答案通常就自己浮现出来了。

再分享一个小经验：代码层面的设计很难一次做对。我在早期写代码时也经常先拍脑袋用接口，后来才发现实现类高度重复，只能回头提取抽象类；有时候反过来，先用抽象类沉淀逻辑，后来发现不相关的类也想接入，又不得不抽出接口。这些都是正常的迭代过程。关键是要保持“面向抽象编程”的直觉——在写具体的 new Xxx() 之前，先想想能否把类型声明成抽象类或接口，让调用方和具体实现彻底解耦。等你养成了这个习惯，再回头去看很多框架源码，就会有一种“原来这里也是多态”的豁然感。

如果这篇文章对你有启发，建议把第四章的消息推送案例自己动手敲一遍，再试着给它加一种新渠道，比如“钉钉机器人”。加完后你会发现，新增一种渠道的成本真的非常低，而这就是抽象类、接口与多态组合起来最直观的价值。