在Java里组合优于继承如何落地_提升代码灵活性的项目实践_技术教程

在Java开发中，“组合优于继承”不是一句空话，而是提升代码可维护性与扩展性的关键设计原则。落地这个理念，核心是用“has-a”替代“is-a”，避免因继承导致的紧耦合和脆弱基类问题。以下通过实际项目场景说明如何将这一原则真正用起来。

用接口+组合替代多层继承

项目中常遇到需要复用行为的情况。比如订单系统中，普通订单、会员订单、团购订单都有“计算总价”的逻辑，但规则不同。若使用继承：

public class Order { ... }
public class MemberOrder extends Order { ... }
public class GroupOrder extends Order { ... }

一旦出现“会员团购订单”，单继承就无法表达多重身份，且父类修改影响所有子类。

改用组合：

public interface PricingStrategy {
double calculatePrice(OrderContext context);
}
public class RegularPricing implements PricingStrategy { ... }
public class MemberPricing implements PricingStrategy { ... }
public class GroupPricing implements PricingStrategy { ... }

订单类持有策略对象：

public class Order {
  private PricingStrategy pricingStrategy;
  public void setPricingStrategy(PricingStrategy strategy) {
    this.pricingStrategy = strategy;
  }
  public double getTotal() {
    return pricingStrategy.calculatePrice(this.context);
  }
}

运行时动态注入策略，无需继承，行为更灵活。

封装共用能力为组件，而非抽象父类

多个服务需要日志记录、权限校验、通知发送等功能。传统做法是写一个 BaseService，其他服务继承它。

问题在于：子类被迫继承所有方法，哪怕用不到；BaseService 一改，全项目受影响。

更好的方式是把通用能力拆成独立组件：

public class NotificationService {
public void send(String to, String msg) { ... }
}
public class AuditLogger {
public void log(String action) { ... }
}

业务服务通过字段引用这些组件：

public class OrderService {
  private NotificationService notifier;
  private AuditLogger auditLogger;
  public OrderService(NotificationService n, AuditLogger a) {
    this.notifier = n;
    this.auditLogger = a;
  }
  public void placeOrder(Order order) {
    auditLogger.log("order placed");
    // ...业务逻辑
    notifier.send(order.getUserEmail(), "下单成功");
  }
}

依赖通过构造函数注入，清晰可控，测试也更容易 mock。