接口 vs 抽象类：为自行车系统选择正确的抽象机制
在面向对象设计中，若需强制子类统一具备状态字段（如 seat、topspeed），应优先使用抽象类；而若仅需约束行为契约（如 startride()、getspeed()），接口更合适——二者可协同使用，而非互斥替代。
在面向对象设计中，若需强制子类统一具备状态字段（如 seat、topspeed），应优先使用抽象类；而若仅需约束行为契约（如 startride()、getspeed()），接口更合适——二者可协同使用，而非互斥替代。
为自行车系统建模时，很多开发者会纠结于技术选型。其实，问题的核心并非“该不该用接口”，而在于你究竟想抽象什么：是所有自行车都必须拥有的物理属性，还是它们都应该支持的操作行为？这两种不同的意图，直接指向了Ja va中两条泾渭分明的设计路径。
接口（Interface）适用于行为契约
接口的本质是定义“能力”或“契约”，它关心的是“能做什么”，而不是“拥有什么”。正因如此，接口无法声明可变的实例字段。它只能通过方法来强制实现类提供具体的行为逻辑。来看一个典型的例子：
public interface Bicycle {
void startRide();
void stopRide();
double getCurrentSpeed();
int getGearCount();
}
这样一来，无论是BMX、山地车还是电动助力车，只要实现了这个接口，就必须给出这些方法的具体实现。至于怎么实现，接口并不关心——电动助力车的startRide()可能涉及启动引擎，而BMX的getGearCount()或许直接返回1。
接口无法声明未初始化的实例字段
这也解释了为什么你会在实践中遇到那个编译错误。下面的写法是行不通的：
// 编译错误！接口中字段默认是 public static final
interface Bicycle {
String seat; // ❌ 必须初始化：String seat = "default";
double topSpeed; // ❌ 同样非法
}
这个限制恰恰印证了接口的设计哲学：它不负责管理对象的状态。所以，接口没法强制要求子类“必须有一个seat字段并自己初始化”，它最多只能要求子类“必须提供一个获取seat信息的方法”。
抽象类（Abstract Class）适用于共享状态与部分实现
那么，当你确实需要所有自行车类型都具备一套共同的属性，比如车座类型、轮径、最高速度和档位数时，该怎么办？答案是：抽象类。它天生就适合封装这些共享的状态，并允许子类在构造时注入具体的值。
public abstract class Bicycle {
protected String seat;
protected double wheelDiameter;
protected double topSpeed;
protected int gears;
// 强制子类通过构造器提供必要状态
protected Bicycle(String seat, double wheelDiameter, double topSpeed, int gears) {
this.seat = seat;
this.wheelDiameter = wheelDiameter;
this.topSpeed = topSpeed;
this.gears = gears;
}
// 可提供默认行为（也可留作 abstract）
public void ringBell() {
System.out.println("Ring!");
}
public abstract void ride(); // 仍可保留抽象方法约束行为
}
有了这个抽象基类，子类的实现就会变得非常清晰和简洁：
public class RoadBike extends Bicycle {
public RoadBike() {
super("Carbon fiber saddle", 0.68, 55.0, 22);
}
@Override
public void ride() {
System.out.println("Gliding on asphalt at up to " + topSpeed + " km/h");
}
}
注意事项与最佳实践
当然，选择抽象类也意味着接受它的约束，最明显的就是单继承限制。在Ja va中，一个类只能继承一个父类，但它可以实现多个接口。这是设计时需要权衡的一点。
另一个关键考量是领域模型的纯粹性。如果某种交通工具（比如无座滑板车）在逻辑上就不应该有seat字段，那么强行把它塞进Bicycle抽象类里，就会破坏模型的语义完整性。这时候，可能需要退一步思考：它真的属于“自行车”这个范畴吗？还是应该引入一个更泛化的基类，比如Vehicle？
话说回来，在复杂的真实系统中，接口和抽象类往往不是二选一的关系，而是相辅相成的伙伴。最佳实践通常是组合使用两者：用抽象类来封装那些共有的状态和基础行为，构建一个坚实的“骨架”；再用接口来刻画那些横向的、多变的能力，为系统注入灵活的“特质”。
public interface Foldable {
void fold();
void unfold();
}
public class BMX extends Bicycle implements Foldable {
// 既拥有自行车的通用属性，又具备可折叠的特有能力
// ... 具体实现
}
所以，接口从来不是“错误”的选择，它只是服务于不同的设计目的。当你发现自己的设计契约里开始出现“必须拥有某个字段”的需求时，这就是一个明确的信号——你真正需要的是抽象类。而接口，应该始终聚焦于定义清晰的行为协议。设计的优雅，往往始于对抽象意图的这份精准把握。
