接口（Interface）、抽象类（Abstract Class）与实体类（Concrete Class）对比

---

🧠 一句话总结

• 接口（Interface）：定义行为规范，没有具体实现。
• 抽象类（Abstract Class）：部分实现+规范，不能直接实例化。
• 实体类（Concrete Class）：完整实现，可以实例化使用。

---

📚 基本定义

类型	说明
接口	只声明方法和属性，不包含实现
抽象类	可包含抽象方法和具体方法，作为子类的模板
实体类	具体类，包含完整实现，可以被实例化

---

🧬 代码示例（TypeScript）

// 接口：定义规范
interface IShape {
  area(): number;
}

// 抽象类：部分实现 + 规范
abstract class Shape implements IShape {
  abstract area(): number;

  describe(): void {
    console.log('This is a shape.');
  }
}

// 实体类：具体实现
class Circle extends Shape {
  constructor(public radius: number) {
    super();
  }

  area(): number {
    return Math.PI * this.radius ** 2;
  }
}

const c = new Circle(5);
console.log(c.area());      // 78.53981633974483
c.describe();               // This is a shape.

背景

「接口（Interface）、抽象类（Abstract Class）与实体类（Concrete Class）对比」对应的是类型系统设计问题，直接影响模块边界清晰度和长期可维护性。

核心原理

Interface 定义“能力契约”，Abstract Class 提供“部分实现 + 强制扩展”，Concrete Class 负责具体落地。
三者不是替代关系，而是分层协作关系。

实现方式 / 示例

建议从业务域建模入手：先定义稳定接口，再抽离通用抽象实现，最后交由具体实体类按场景实现。

常见问题

1. 把接口当作“字段清单”，缺少语义约束。
2. 抽象类承担过多业务逻辑，导致继承层级僵化。
3. 实体类职责不清，边界不断漂移。

最佳实践

优先组合而非深继承；在评审中检查“契约稳定性、扩展成本、替换能力”三项指标。

总结

围绕「接口（Interface）、抽象类（Abstract Class）与实体类（Concrete Class）对比」的核心是建立可演进的类型分层，而不是追求语法层面的“完备”。