为何使用Interface而非普通类？新手对强制契约的困惑

嘿，这个问题问得特别戳痛点——很多刚搞懂接口语法的开发者，都会卡在「明明直接写类也能实现功能，为啥非要搞个强制契约出来」这一步！咱们就拿你说的酒店预订场景来拆解，你就能明白契约的核心价值了。

核心原因1：统一交互语言，避免「鸡同鸭讲」 #

假设你现在要做一个旅游平台，除了酒店H，还要接入酒店K、民宿B、连锁公寓C。如果没有接口契约：

• 酒店H的预订方法叫bookRoom()
• 酒店K可能叫reserveRoom()
• 民宿B甚至可能叫holdStay()

那你写平台的预订逻辑时，就得针对每个商家写一堆if-else判断：「如果是H酒店就调这个方法，如果是K酒店就调那个」——这代码维护起来简直是噩梦！

但如果定义了一个Bookable接口（契约），要求所有可预订的住宿必须实现checkAvailability()和book()这两个方法，那不管是H还是K还是B，平台只要调用统一的方法就行，完全不用管对方内部是怎么实现的。这就像所有商家都同意用「预订」这个词沟通，而不是各说各的方言。

核心原因2：约束行为，保证对外功能的稳定性 #

接口就像一份公开的承诺：「只要你用我，我就肯定提供这些功能」。比如酒店H的开发者某天心血来潮，想把bookRoom()改成reserve()，如果没有接口约束，他改完自己爽了，但所有调用H酒店的代码全得崩。

但有了接口契约，IDE会直接报错，提醒他「你必须实现接口里的bookRoom()方法」——这就强制他不能随便破坏对外的功能约定，保证了依赖方的代码稳定性。

核心原因3：解耦代码，让扩展变得简单 #

还是拿旅游平台举例：如果你的预订服务直接依赖HotelH这个具体类，以后要加酒店K，你就得修改预订服务的代码，把K的逻辑加进去。但如果预订服务依赖的是Bookable接口，那只要酒店K实现了这个接口，直接就能塞进预订服务里用，完全不用动原有代码——这就是咱们常说的「开闭原则」：对扩展开放，对修改关闭。

给你看个简化的代码示例更直观：

// 定义契约：所有可预订住宿必须遵守的规则
interface Bookable {
    boolean checkAvailability(String type, LocalDate date);
    boolean book(String type, LocalDate date, String guest);
}

// 酒店H遵守契约实现功能
class HotelH implements Bookable {
    @Override
    public boolean checkAvailability(String type, LocalDate date) {
        // H酒店自己的库存查询逻辑
        return true;
    }

    @Override
    public boolean book(String type, LocalDate date, String guest) {
        // H酒店自己的预订系统调用逻辑
        return true;
    }
}

// 预订服务只依赖契约，不依赖具体酒店
class BookingPlatform {
    public boolean makeBooking(Bookable accommodation, String type, LocalDate date, String guest) {
        if (accommodation.checkAvailability(type, date)) {
            return accommodation.book(type, date, guest);
        }
        return false;
    }
}

说白了，接口契约的本质就是把「要做什么」和「具体怎么做」彻底分开——它保证了协作的各方（不管是不同的类、不同的团队甚至不同的系统）都遵守同一个规则，既减少了沟通成本，又让代码更易维护、更灵活。

内容的提问来源于stack exchange，提问作者avi