Java中复用公共服务类：继承基类与组合基类哪种方案更合理？

继承Base基类的做法存在明确缺陷，不建议使用 #

缺陷主要集中在以下几点：

• 违反面向对象设计的is-a核心原则：继承的适用前提是子类和父类存在明确的从属关系，而你的场景中A、B、C仅仅是需要用到相同的服务依赖，和Base类没有本质的从属属性，强行使用继承会导致类层次逻辑混乱，后续维护无法快速厘清继承关系的设计目的。
• 灵活性严重不足：如果后续某类子类不需要某个公共服务，继承得到的冗余成员无法单独移除；如果不同子类需要的公共服务组合存在差异，要么在Base中叠加更多服务导致所有子类都承担冗余依赖，要么拆分多个Base类引发继承层次爆炸、多重继承混乱的问题。
• 封装与耦合问题：如果公共服务在Base中声明为private，子类访问需要额外写大量getter方法，本质没有减少太多冗余代码；如果声明为protected，又会把服务成员暴露给整个继承体系，违反最小暴露原则，提升了不必要的耦合度。

更优的复用方案 #

你提到的嵌套组合方案比继承更合理，还有更灵活的实现可选：

方案1：公共服务容器组合 #

将所有公共服务封装到一个独立的服务容器类中，A、B、C各自持有该容器的实例即可。这种方案完全解耦了公共服务和业务类的逻辑，后续调整公共服务只需要修改容器类，不会影响业务类的结构，也可以灵活给单个业务类添加独有的依赖。
示例实现参考：

// 公共服务容器，仅负责持有和初始化公共服务
class CommonServiceContainer {
  private ClassX serviceClassX;
  private ClassY serviceClassY;
  private ClassZ serviceClassZ;

  // 对应服务的getter、初始化逻辑
  public ClassX getServiceClassX() { return serviceClassX; }
  // 其余getter省略
}

// 业务类实现
class A {
  private CommonServiceContainer commonServices;
  // A类独有的属性、方法
}

方案2：依赖注入（适用有DI框架的场景） #

如果项目使用支持依赖注入的框架（如Spring、Guice等），可以不用自己封装容器，直接给需要的业务类注入对应的服务即可。这种方式代码更简洁，还可以灵活控制每个业务类的依赖范围，甚至给不同业务类注入同类型服务的不同实现，灵活度最高。

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