在Java里组合优于继承如何落地_提升代码灵活性的项目实践
在Java开发中，“组合优于继承”不是一句空话，而是提升代码可维护性与扩展性的关键设计原则。落地这个理念，核心是用“has-a”替代“is-a”，避免因继承导致的紧耦合和脆弱基类问题。以下通过实际项目场景说明如何将这一原则真正用起来。
用接口+组合替代多层继承
项目中常遇到需要复用行为的情况。比如订单系
统中，普通订单、会员订单、团购订单都有“计算总价”的逻辑，但规则不同。若使用继承：
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。
避免“为了复用”而继承
常见误区：发现两个类有相同字段或方法，就提取父类。比如 User 和 Admin 都有 name、email，于是建 BaseUser。
但随着演化，User 可能加 address，Admin 加 roleLevel，父类越来越臃肿，子类也被迫承担无关字段。
更合理的做法是提取共用数据结构：
public class ContactInfo {private String name;
private String email;
}
User 和 Admin 内部包含 ContactInfo：
public class User {private ContactInfo contact;
private Address address;
}
这样变化隔离，也能实现代码复用，且不影响各自演进。
基本上就这些。组合让类职责更单一，依赖更明确，系统更容易应对需求变化。关键是转变思维：不要一上来就想“XX是不是一种YY”，而是问“XX有没有YYY能力”。
