接口和类的区别详解：从语法到设计选型，一篇讲透面向对象核心概念

接口和类这组概念，几乎每一位学面向对象编程的人都纠结过。尤其是面试被人问“接口与类的区别”时，很多人能背出“接口用 interface、类用 class、类能 new、接口不能 new”，但真到了自己设计一个业务模块，还是不知道什么时候该写接口、什么时候该写类。我在项目里见过不少把接口当成装饰品、或者把类当成万能容器的写法，最后代码改起来非常痛苦。这篇就把两者从语法到设计一层层拆开，讲清楚它们各自的角色、核心区别、以及实际工程里怎么选型，适合正在学 Java/C# 的读者，也适合已经写了一阵子代码但想补一补基础设计能力的人。

先记住一句话：“类描述的是对象是什么，接口描述的是对象能做什么”。这句话看起来简单，却几乎是所有后续理解的分水岭。

1. 本质拆解：类与接口各自的角色定位

1.1 类：具体对象的模具

类是通过 class 关键字定义出来的类型，它把数据和行为打包在一起。一个类里可以有成员变量，用来描述对象的状态，比如“学生”这个类，有学号、姓名、班级这些字段；也可以有方法，用来描述对象的行为，比如选课、打卡。类最大的特点是有完整的实现，可以直接通过 new 创建一个对象出来，这个对象拥有类定义的所有状态和动作。

可以把它当成做蛋糕的模具。模具的尺寸、形状都是确定的，一旦模具做好，你往里面倒面糊，出来就是一个成型的蛋糕。类也一样，它的字段决定了对象“有什么”，方法决定了对象“会做什么”，一切都落实到了具体的代码里。所以类在 OOP 里扮演的是“具体事物的模板”这个角色。

1.2 接口：行为能力的契约

接口用 interface 关键字定义，它与类最大的不同是：它不关心实现细节，只关心“有没有某个能力”。接口里声明的方法没有方法体，只规定了方法的签名，也就是调用方能看到的方法名、参数、返回值。真正的方法逻辑由实现接口的类去写。

比如“自动驾驶”是一个能力，接口会声明 void autoDrive();，但至于自动驾驶是靠激光雷达、摄像头还是别的什么方案，接口不管。这份约定有点像租房合同：合同上写明了“每个月要交房租”，至于租客怎么把钱转过来、用哪个银行，合同不关心。接口在代码里充当的正是这种契约角色，它告诉外界“我能提供这些操作”，但不透露内部怎么实现。

1.3 一句话理解它们的关系

类与接口不是对立的，而是协作的。一个类可以继承另一个类，同时实现一个或多个接口。比如“救护车”类继承“机动车”类，这表达的是“救护车是一种机动车”；救护车又实现“鸣笛”接口，表达的是“救护车具备鸣笛能力”。

如果用一句话总结：类是对具体事物的抽象，接口是对行为能力的抽象。理解了这层关系，再往下看各种语法规则，才会有“原来如此”的感觉，而不是死记硬背。

2. 接口与类的核心区别，逐条拆开看

2.1 一张表快速看全貌

这张表是基础，但光看表不够，下面把每一条背后“为什么这样设计”也讲透。

2.2 实例化：能不能 new 是最大分水岭

类可以实例化，接口不能，这是二者最容易感知的区别。为什么接口不能 new？因为接口不是一个“完整的东西”，它没有成员变量，没有构造方法，也没有具体的方法实现。你就算硬要 new 一个接口出来，也得不到一个有状态的、能干活的对象。打个比方，合同本身不能住人，能住人的是拿着合同去租下来的那套房子。

Java 里允许匿名内部类和 lambda 来实现接口，感觉上像是“new 了一个接口”，实际创建的是接口的匿名实现类对象，本质还是实现类的实例。所以别把这种写法误认为“接口可以实例化”。每次见到 new，都要问一个问题：这个类型有没有完整的状态和实现？没有的话，它就只能是一份契约。

2.3 成员与方法的差异：接口里为什么只能有常量

类的字段可以是实例变量，每个对象都有自己的一份，比如每个学生对象有各自的姓名。接口里做不到这一点，接口里只能有 public static final 常量，这是 Java 语法强制规定的。这样设计的好处是安全性：接口表达的是能力契约，如果接口可以存放可变的状态，状态一变，所有实现类的行为都会受影响，还要处理复杂的状态同步，契约就不稳定了。干脆只允许常量，从根上避免这个问题。

方法上的差异更明显。普通类里的每个方法都要有方法体，否则就是抽象类；接口在 Java 8 之前只有抽象方法，Java 8 之后加入了 default 和 static 方法，但整体基调还是以抽象为主。default 方法解决的是接口演进和代码复用的问题，后面单独说，但不要把接口写成一个满是业务逻辑的类，那是本末倒置。

2.4 继承机制：单继承与多实现的取舍

类之间是单继承，一个子类只能有一个直接父类。Java 这么设计是为了避免“钻石问题”：如果 C 同时继承 A 和 B，而 A、B 都有同一个方法或字段，C 到底继承哪一份？状态和方法的多义性会让语言变得复杂。

接口不一样。接口之间可以多继承，一个类也可以同时实现多个接口，因为接口没有实例状态，多个抽象方法签名合并到一起时，不会产生“状态不一致”的问题。比如一个类可以实现“可飞行”接口，也可以实现“可检修”接口，飞行和检修两种能力的抽象方法都能被同一个类同时兑现。

Java 8 之后接口引入了 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() {
        A.super.hello();
        B.super.hello();
    }
}

如果实现类不重写这个 hello，编译器会直接报错，要求你解决冲突。所以接口的多实现依然有规则，只不过比类的多继承温和得多。

2.5 抽象类这个“第三种选择”怎么定位

讨论接口和类的时候，抽象类总会被拉进来一起对比。抽象类本质上是“半成品类”：它被 abstract 修饰，不能被实例化，但可以有字段、构造方法、实例方法，也可以有抽象方法留给子类实现。

典型的例子是“门”和“报警器”。普通门可以抽象成一个类，它有开门、关门的通用逻辑；报警器是一个接口，能力是发出警报。那么“报警门”类可以继承门类、实现报警器接口，既是一个门，也具备报警能力。反过来，如果让“报警门”继承“报警器”类，就变成“报警门是一种报警器”，语义上完全说不通。这个例子能帮你快速判断：用类表达“是什么”，用接口表达“能做什么”。

3. 接口真正的价值：解耦与面向接口编程

3.1 为什么大家都在说“面向接口编程”

面向接口编程不是口号，而是为了解决真实的维护问题。假设 A 模块要调用 B 模块，如果 A 代码里直接 new 一个 B 的具体类，那么 A 就被死死绑定在 B 上。B 类未来要换一种实现方式、改一个方法、甚至被整个替换，A 都得跟着改代码。

接口把“调用方”和“实现方”隔开了。A 只依赖于接口里声明的方法，不关心具体是哪个类在干活。这个思路和电脑上的 USB-C 接口一模一样：设备那一头只要符合 USB-C 规范，电脑这一头就不需要知道充电器、硬盘、显示器分别是谁家做的。类负责把自己“做成符合规范的样式”，接口负责维持“插口”的稳定。

3.2 一个支付场景的改造过程：从 if 堆砌到接口统一

我在一个模拟电商项目里见过最典型的坏味道：把所有支付逻辑都堆在一个类里，用 if 判断支付类型。那时候的代码长这样：

java复制public class PaymentService {
    public void pay(String type, BigDecimal amount) {
        if ("channelA".equals(type)) {
            // 调用渠道 A 的接口，生成签名，发起扣款
        } else if ("channelB".equals(type)) {
            // 调用渠道 B 的接口，生成签名，发起扣款
        } else if ("channelC".equals(type)) {
            // 调用渠道 C 的接口，生成签名，发起扣款
        }
    }
}

这个类最大的问题是什么？每次接入新支付渠道，都要回来改这个类。改到后来，一个方法几百行，测试要覆盖所有分支，而且渠道 A 的代码出问题，整个类都要重新发布。这就是典型的“面向具体类编程”导致的耦合。

改成接口之后，结构会清楚很多。先定义一个支付能力契约：

java复制public interface PaymentService {
    void pay(BigDecimal amount);
    String channelName();
}

渠道 A 和渠道 B 各自实现这个接口：

java复制public class ChannelAPayService implements PaymentService {
    private final String apiKey;

    public ChannelAPayService(String apiKey) {
        this.apiKey = apiKey;
    }

    @Override
    public void pay(BigDecimal amount) {
        // 渠道 A 的签名、请求、回执处理
        System.out.println("ChannelA paid " + amount);
    }

    @Override
    public String channelName() {
        return "ChannelA";
    }
}

public class ChannelBPayService implements PaymentService {
    @Override
    public void pay(BigDecimal amount) {
        // 渠道 B 的签名、请求、回执处理
        System.out.println("ChannelB paid " + amount);
    }

    @Override
    public String channelName() {
        return "ChannelB";
    }
}

下单模块只依赖接口：

java复制public class CheckoutService {
    private final PaymentService paymentService;

    public CheckoutService(PaymentService paymentService) {
        this.paymentService = paymentService;
    }

    public void checkout(BigDecimal amount) {
        paymentService.pay(amount);
    }
}

组合的时候再决定具体用哪个实现：

java复制public class Application {
    public static void main(String[] args) {
        PaymentService paymentService = new ChannelAPayService("key-123");
        CheckoutService checkoutService = new CheckoutService(paymentService);
        checkoutService.checkout(new BigDecimal("100"));
    }
}

这样改完，新增支付渠道就只需要增加一个新的实现类，下单模块一行代码都不用动。调用方和实现方被接口隔开，这就是解耦，也是接口在工程上最核心的价值。

3.3 类在接口背后做什么

这个例子里，类也没有消失。具体的状态，比如渠道 A 的 apiKey、接口地址、超时时间、日志记录，全放在实现类里。接口只约定了“谁都能来支付”，但支付时用的密钥、请求方式、回调处理，全部由各个实现类自己管理。

类负责“做”，接口负责“说”。这句话放到具体代码里，就是实现类默默完成繁琐的细节，接口向外部暴露一个清爽的入口。

3.4 接口也在进化：default 方法和 static 方法

Java 8 之前，接口一旦发布，再想往里面加方法，所有实现类都面临“必须补实现”的灾难。为了兼容旧实现，Java 8 引入了 default 方法，允许在接口里提供默认实现，已有实现类不改代码也能正常编译。

比如要给支付接口统一加一个“打日志”的默认方法：

java复制public interface PaymentService {
    void pay(BigDecimal amount);
    String channelName();

    default void logPayment() {
        System.out.println("Payment done via " + channelName());
    }
}

但我要提醒一句：默认方法是给接口演进用的，不是给接口写业务逻辑用的。如果一个接口里堆了五六个 default 方法，每个方法内部都有一大段真实业务逻辑，那这个接口已经退化成了抽象类的变体，失去了契约的意义。

4. 实际选型：什么时候用接口，什么时候用类

4.1 用四个问题确定答案

面对一个新需求，我可以给你一个判断顺序：

1. 这个类型描述的是一个具体的、有状态的东西吗？比如“订单”“用户”“日志记录”——如果是，优先用类。
2. 多个毫无血缘关系的类都需要执行同一种动作吗？比如“打印”“排序”“支付”——如果是，优先用接口。
3. 多个类之间既有公共代码，又有各自不同的实现细节吗？比如要把整个订单处理流程做成模板，公共步骤放父类，不同渠道的差异留给子类——这种情况用抽象类更顺手。
4. 你只是想传递一串数据，不需要任何行为吗？那连复杂的类都不用，直接用普通类当数据载体，必要时用 record/DTO 之类。

核心思路是：先想“这个东西是什么”，再想“它有没有能力扩展”。不要一上来就讨论用接口还是类，先讨论业务语义。

4.2 从测试和维护的角度倒推

接口的另一大价值体现在测试上。一个服务如果依赖具体类，单元测试里想替换成假的实现，就要想办法构造真实依赖，非常麻烦。依赖接口的话，测试框架可以很轻松地生成 mock 对象，或者你自己写一个测试用的假实现类。

举个例子，下单服务依赖支付接口，测试时你可以传一个“只打印日志、不真正扣款”的假实现，不需要启动真实的支付渠道：

java复制public class MockPaymentService implements PaymentService {
    @Override
    public void pay(BigDecimal amount) {
        System.out.println("mock pay");
    }

    @Override
    public String channelName() {
        return "mock";
    }
}

维护上同理。接口给未来的替换留了一扇门，当你看代码的时候，只要调用方依赖的是接口，你就知道换实现是相对容易的；如果到处都依赖具体类，改动一处可能会牵扯一串地方。

4.3 关于“每个类都要配接口”的忠告

很多新手从教材里学到一个观念：提倡面向接口编程，于是恨不得每个类先写一个接口。我见过一个模拟项目，订单模块被拆成五个接口、七个类，每个接口文件只有一两个方法，查一个简单的业务问题要在十来个文件之间跳来跳去，反而把代码变得又碎又难读。

接口是有成本的。每个接口都意味着多一层抽象、多一层跳转、多一层理解负担。所以在要不要加接口这件事上，我的原则是：只有当“替换、模拟、多态”这三个维度里至少有一个是真实需求时，才引入接口。如果这个能力在当前业务里只会有一个实现，并且短期内看不到第二个实现的可能，直接写类，等真的有需要时再抽接口也不迟。记住一句话：代码设计里的很多东西，欠着比急着还要好，过度设计是维护的地狱。

5. 常见问题与排查心得

5.1 报错“interface expected”或者“cannot be instantiated”是怎么回事

这种情况绝大多数是试图 new 一个接口，或者把接口当普通类用了。接口不是完整类型，不能直接实例化。解决办法很简单：改成接口的实现类。比如 List 是接口，你写 new List<>() 会报错，但 new ArrayList<>() 就没问题。记住这个典型例子，面试和日常写代码都经常遇到。

5.2 普通类实现接口，方法没写全会怎么样

普通类实现了接口但只实现了一部分方法，编译器会直接报错：必须实现接口的所有抽象方法。如果这个类本身是抽象类，则可以只实现一部分，剩下的继续留给子类。所以看到一个类“实现”了接口却缺少方法体，要么是漏写，要么是漏了 abstract 修饰符。排查时先确认这个类是普通类还是抽象类。

5.3 两个接口出现同名默认方法，实现类该怎么做

这在前面已经提到过。实现类必须重写那个冲突的方法，否则无法编译。重写时可以用 A.super.方法() 或 B.super.方法() 指定调用哪个接口的默认实现，或者直接自己写一套全新逻辑。我建议遇到这种场景先停下来想想：一个实现类同时拥有两个有默认方法的接口，是不是设计上已经有点绕了？多数情况下，调整接口粒度会让代码更清爽。

5.4 排错速查表

5.5 几个我常用的避坑习惯

接口设计最基本的一条，是用调用方的视角去定义方法。接口不是写给自己看的，是写给使用方看的，方法名要直白，参数要少而清晰。一个接口最好只表达一种能力，比如“可支付”和“可退款”是两个能力，混在一个接口里会让某些只支持支付、不支持退款的实现类很难办。

另外，别把接口当成常量仓库。Java 接口里虽然能定义常量，但把一堆配置常量塞进接口，然后让实现类去继承，会让接口失去“能力契约”的意义。真要放常量，直接写到专门的常量类里，干简单的事。

6. 最后分享一点我的实操体会

我这些年写代码有一个很深的感受：接口和类谁更好，从来不是一道二选一的选择题，而是要看你在描述世界的哪一面。类用来承载确定性，把数据和行为收拢在一起，形成稳定的骨架；接口用来保留可能性，让一个系统在未来的扩展中不至于每走一步都伤筋动骨。真正好读的代码，往往是骨架清楚、接口克制、实现专注。自己动手做一个小项目时，可以先从类写起，把一个需求跑通，再回头看看哪一部分存在替换或扩展的空间，把接口加在真正需要的位置。这样做出来的设计，比照着设计模式硬套要自然得多。