何时使用抽象(Abstraction)与接口(Interface)？选型判断依据咨询

以下是直接指导你选择抽象类或接口的核心判断变量，结合场景和代码示例说明：

1. 是否需要共享可复用的实现逻辑 #

• 选抽象类：当多个子类存在共同的代码逻辑时，抽象类可以定义非抽象方法（带具体实现），让子类直接继承复用。比如多个支付渠道都需要记录支付日志，这个通用逻辑放在抽象类里最合理。

  abstract class Payment {
      // 所有支付子类共享的日志实现
      protected void logTransaction(String orderId) {
          System.out.println("已记录支付流水：" + orderId);
      }
  
      // 子类必须实现的核心支付逻辑
      public abstract void execute(double amount);
  }
  
  class WechatPay extends Payment {
      @Override
      public void execute(double amount) {
          logTransaction("WX_123");
          System.out.println("微信支付：" + amount + "元");
      }
  }
  

• 选接口：如果只需要定义行为规范，不需要共享代码，所有实现类各自实现逻辑。比如定义"可飞行"的行为，不同生物的飞行方式完全不同，不需要复用逻辑。

  interface Flyable {
      void fly();
  }
  
  class Bird implements Flyable {
      @Override
      public void fly() {
          System.out.println("煽动翅膀飞行");
      }
  }
  
  class Plane implements Flyable {
      @Override
      public void fly() {
          System.out.println("引擎推动飞行");
      }
  }
  

2. 继承关系是否符合"is-a" vs "can-do" #

• 选抽象类：当子类和抽象类是同一类别的关系（is-a），比如Animal抽象类，Dog、Cat都是Animal的子类，属于同一实体范畴。
• 选接口：当类和接口是行为能力的关系（can-do），比如Runnable接口，Thread、Task都可以具备"可运行"的能力，但它们不属于同一类别。

3. 是否需要维护实例状态 #

• 选抽象类：抽象类可以定义成员变量来维护实例状态，比如Car抽象类可以有fuelLevel（油量）变量，子类GasCar、ElectricCar可以继承并修改这个状态。

  abstract class Car {
      protected int fuelLevel;
  
      public Car(int initialFuel) {
          this.fuelLevel = initialFuel;
      }
  
      public abstract void refuel();
  }
  
  class GasCar extends Car {
      public GasCar(int initialFuel) {
          super(initialFuel);
      }
  
      @Override
      public void refuel() {
          fuelLevel += 50;
          System.out.println("加汽油后油量：" + fuelLevel);
      }
  }
  

• 选接口：接口只能定义静态常量（无法维护实例级状态），如果不需要状态管理，仅定义行为，选接口。

4. 是否需要多行为组合 #

• 选抽象类：多数语言（如Java、C#）仅支持单继承，如果类的扩展属于单一继承体系下的细化（比如从Vehicle到Car再到ElectricCar），用抽象类。
• 选接口：如果一个类需要具备多种独立的行为，比如Robot需要同时具备Moveable、Speakable、Cleanable三种能力，用接口组合（因为可以实现多个接口）。

5. 契约稳定性 vs 实现演进性 #

• 选接口：接口是稳定的行为契约，一旦发布就不应轻易修改（否则所有实现类都要同步调整）。适合定义通用、长期不变的规范，比如Serializable（序列化）、Comparable（可比较）。
• 选抽象类：抽象类可以在后续版本中新增非抽象方法（只要不强制子类实现），不会破坏现有子类的兼容性。适合需要逐步演进的基础类，比如框架中的基类，后续可以新增通用工具方法。

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