最近又在评审代码时看到一种熟悉的味道：一个 BaseDao 被十几个子类继承，子类为了复用父类一个查询方法，被迫把连接管理、异常处理、日志打印全部继承下来；改一下父类的关闭连接逻辑，下游三个服务同时报错。我是老李。今天借这个场景，聊一个很基础但总被忽略的原则——合成聚合复用原则。为什么现在要讲？因为系统越拆越细，业务变化越来越快，用继承偷来的复用，最后都会变成技术债。

## 01、痛点

先看一个常见的 Java 写法：

```java
public class BaseService {
    public void checkAuth() { ... }
    public void recordLog() { ... }
    public void sendMessage() { ... }
}

public class OrderService extends BaseService {
    public void createOrder() {
        checkAuth();
        // 创建订单
        recordLog();
    }
}
```

表面上看，OrderService 复用到了 checkAuth 和 recordLog，少写两段代码。但问题也埋下了：

- OrderService 其实不是 BaseService，业务语义上“订单服务是一个基础服务”并不成立。
- OrderService 被迫继承了 sendMessage，但订单服务根本不需要发消息。
- 如果 BaseService 为了另一个子类修改 checkAuth 方法签名，OrderService 也必须跟着变。
- Java 只有单继承。某天 OrderService 还想复用缓存组件，只能继续往 BaseService 里塞，或再抽一层，继承链越来越深。

这种结构可以画成一条脆弱的链：

```
BaseService
   ├── OrderService
   ├── UserService
   └── VipOrderService
         └── ...
```

一旦 BaseService 里有方法变更，所有子类都会被动受影响。更麻烦的是，父类内部状态对子类可见，子类可能绕过对外接口直接操作父类字段，破坏封装。继承变成一把双刃剑：短期少写代码，长期多还债。

## 02、是什么

合成聚合复用原则的英文全称是 Composite/Aggregate Reuse Principle，有时简称 CARP。它说的是：尽量使用对象组合和聚合，而不是类继承来达到复用目的。

在 Java 里，组合和聚合都是“一个类持有另一个类引用”的实现方式，但强度不同：

- 组合：整体负责部分的完整生命周期，部分不能脱离整体单独存在。比如汽车与引擎，引擎由汽车创建，汽车销毁时引擎也一起销毁。
- 聚合：整体与部分之间是较弱的拥有关系，部分可以独立存在。比如球队与球员，球员可以离开球队继续存在。

用字符画表示：

```
组合（强关系）
┌──────────┐       ┌──────────┐
│   Car    │◆─────▶│  Engine  │
└──────────┘       └──────────┘

聚合（弱关系）
┌──────────┐       ┌──────────┐
│   Team   │◇─────▶│  Player  │
└──────────┘       └──────────┘
```

对应到 Java 代码，组合通常是：

```java
public class Car {
    private final Engine engine;
    
    public Car() {
        this.engine = new Engine();
    }
}
```

而聚合通常是通过构造器或 setter 注入：

```java
public class Team {
    private final List<Player> players;
    
    public Team(List<Player> players) {
        this.players = players;
    }
}
```

组合与聚合的本质都是“持有对象做委派”，所以更宽泛地说，合成聚合复用原则就是优先用“持有”替代“继承”。

## 03、为什么

为什么这个原则值得遵守？因为继承解决的是“我是什么”，组合解决的是“我有什么”。大多数业务功能复用，本质上是“我有什么能力”，而不是“我是什么类型”。

继承有三个明显短板。

第一，继承破坏封装。父类的实现细节对子类可见，子类可能依赖父类某个方法的内部逻辑。一旦父类修改，所有子类都处于风险之中。

第二，继承是编译期绑定，组合是运行期绑定。继承关系在类加载时就已经固定，无法根据场景动态替换。组合则可以通过接口切换实现。

第三，继承受单继承限制。Java 里一个类只能有一个直接父类，但一个类可以组合任意多个接口实现。

举个例子，如果一个支付服务需要同时复用日志、缓存、消息通知三种能力，用继承很难优雅实现，而用组合只需要注入三个组件即可。

下面这张表对比了两种复用方式：

| 维度 | 继承 | 组合/聚合 |
|---|---|---|
| 关系 | is-a | has-a |
| 绑定时机 | 编译期 | 运行期 |
| 耦合程度 | 高 | 低 |
| 封装性 | 破坏封装 | 保持封装 |
| 扩展性 | 弱 | 强 |

所以，组合让代码更符合开闭原则：新增能力时，不修改已有类，而是新写一个类，再组合进去。

## 04、架构

在架构层面，这个原则同样重要。很多老项目会设计一个庞大的 BaseService 或 BaseController，把公共逻辑放在最顶层，再让所有业务类继承。这看起来像统一治理，但往往导致架构僵化。

更健康的方式是，业务类只保留业务骨架，通过组合方式持有所需的领域对象、仓储接口和外部客户端。例如一个订单服务：

```java
public class OrderServiceImpl implements OrderService {
    private final OrderRepository orderRepository;
    private final PaymentGateway paymentGateway;
    private final MessageSender messageSender;

    public OrderServiceImpl(OrderRepository orderRepository,
                            PaymentGateway paymentGateway,
                            MessageSender messageSender) {
        this.orderRepository = orderRepository;
        this.paymentGateway = paymentGateway;
        this.messageSender = messageSender;
    }

    public void createOrder(Order order) {
        orderRepository.save(order);
        paymentGateway.pay(order.getTotalAmount());
        messageSender.send(order.getOrderNo());
    }
}
```

这里没有继承任何 BaseService，但订单服务仍复用了仓储、支付、消息三种能力。每个组件都是接口定义，OrderServiceImpl 只依赖接口，不关心具体实现。

这种结构可以画成：

```
OrderServiceImpl
    ├──▶ OrderRepository
    ├──▶ PaymentGateway
    └──▶ MessageSender
```

在微服务或模块化架构里，各模块之间也建议通过组合/聚合来协作，而不是让每个服务都继承一个通用基类。比如用户服务需要通知能力，就组合一个通知客户端；订单服务需要用户信息，就聚合一个用户客户端。这样的系统边界清晰，替换实现也更安全。

## 05、实战

下面通过一个完整的通知发送场景，展示从继承到组合的改造。

先用继承实现：

```java
public class Notifier {
    public void send(String message) {
        // 默认邮件
    }
}

public class SmsNotifier extends Notifier {
    @Override
    public void send(String message) {
        // 发短信
    }
}

public class WechatNotifier extends Notifier {
    @Override
    public void send(String message) {
        // 发微信
    }
}
```

现在需求变了：要同时给用户发邮件和短信。继承方式下，要么新建一个 EmailAndSmsNotifier 再复制两份逻辑，要么再抽一层，都很别扭。

改成组合，先定义接口：

```java
public interface MessageSender {
    void send(String message);
}
```

实现三种发送器：

```java
public class EmailSender implements MessageSender {
    @Override
    public void send(String message) {
        // 发送邮件
    }
}

public class SmsSender implements MessageSender {
    @Override
    public void send(String message) {
        // 发送短信
    }
}

public class WechatSender implements MessageSender {
    @Override
    public void send(String message) {
        // 发送微信
    }
}
```

然后让一个组合发送器持有多个发送器：

```java
public class CompositeMessageSender implements MessageSender {
    private final List<MessageSender> senders;

    public CompositeMessageSender(List<MessageSender> senders) {
        this.senders = senders;
    }

    @Override
    public void send(String message) {
        for (MessageSender sender : senders) {
            sender.send(message);
        }
    }
}
```

使用时：

```java
MessageSender sender = new CompositeMessageSender(List.of(
    new EmailSender(),
    new SmsSender()
));
sender.send("订单已发货");
```

还可以继续叠加装饰能力，比如给发送器增加重试：

```java
public class RetryableMessageSender implements MessageSender {
    private final MessageSender delegate;
    private final int maxAttempts;

    public RetryableMessageSender(MessageSender delegate, int maxAttempts) {
        this.delegate = delegate;
        this.maxAttempts = maxAttempts;
    }

    @Override
    public void send(String message) {
        for (int i = 0; i < maxAttempts; i++) {
            try {
                delegate.send(message);
                return;
            } catch (RuntimeException e) {
                // 重试
            }
        }
    }
}
```

使用时可以像搭积木一样组合：

```java
MessageSender sender = new RetryableMessageSender(
    new CompositeMessageSender(List.of(
        new EmailSender(),
        new SmsSender()
    )),
    3
);
sender.send("订单已发货");
```

可以看到，扩展新能力不需要修改已有类，只需要新增类并组合。这就是合成聚合复用原则带来的灵活性。实际业务中，订单支付、日志审计、权限校验等场景都可以用同样的方式改造。

## 06、洞见

很多人把继承当成复用的首选，是从学习面向对象的第一天起就形成的惯性。但复用的前提是关系正确。合成聚合复用原则并没有否定继承，而是提醒我们：只有在真正满足 is-a，并且需要多态替换时，才应该使用继承。

一个常见的判断标准是里氏替换原则：如果子类不能在所有使用父类的地方安全替换父类，就不应该继承。现实中很多 BaseService 的子类并不满足这个条件，它们只是贪图父类里的几个方法。

组合则让每个类都保持单一职责。发送类只负责发送，重试类只负责重试，组合之后能力自然叠加。代码库也更容易测试：测试重试逻辑时，可以传入一个假的发送器，而不必继承某个基类。

字符画对比：

```
继承的思维：
能力在父类，子类是“一类东西”

组合的思维：
能力在组件，业务类“拼装”能力
```

设计模式中的策略模式、装饰器模式、观察者模式、桥接模式，背后都有合成聚合复用原则的影子。它们都用对象之间的持有与转发，替代了继承的静态绑定。

## 07、行动

落到日常编码，可以给自己列一个检查清单：

```
□ 我是不是为了复用某几个方法才写 extends？
□ 子类和父类之间真的是 is-a 关系吗？
□ 父类修改时，子类是否可能被意外影响？
□ 我是否只需要父类的部分能力？
□ 如果未来需要替换实现，继承能做吗？
```

如果前四个问题里任何一个答案是“是”，就应该优先考虑组合。

具体行动建议：

1. 优先定义小接口，把能力拆成可组合的单元。
2. 通过构造器或 setter 注入所需组件，而不是继承一个基类。
3. 只在以下情况使用继承：确实存在稳定的抽象层次，且父类主要定义算法骨架或公共契约。例如模板方法模式中，父类定义流程，子类实现钩子方法。
4. 控制继承深度。如果继承链超过两层，就要停下来看看是否可以用组合替代。
5. 对既有的 BaseService、BaseDao 进行定期重构：把公共方法抽到独立组件中，再让业务类组合这些组件。
6. 理解组合与聚合的差异，选择正确的关系：整体管理部分生命周期用组合，部分可独立存在用聚合。

行动第一步可以从一个小模块开始：找出一个你最想干掉的 BaseXxx，把它拆成两个接口和两个实现，用组合装配回业务类。做完这次，你会对这条原则有更真实的体感。

## 08、小结

继承解决“我是什么”，组合解决“我有什么”。大多数业务代码需要的不是更深的继承树，而是更灵活的对象拼装。

合成聚合复用原则的价值，不在于背下定义，而在于每次写下 extends 之前，多问一句：这个类真的需要“是”它吗？还是只需要“有”那个能力？

把继承留给真正稳定的抽象，把复用交给组合。代码会变得更薄、更清晰，也更经得起业务变化的折腾。

## 09、链接与概念说明

概念澄清：

- 合成聚合复用原则：面向对象设计原则之一，核心是优先使用对象组合和聚合，而不是类继承来复用代码。
- 组合（Composite）：整体与部分生命周期一致，整体负责创建和销毁部分。Java 中通常表现为成员变量在类内部 new 出来。
- 聚合（Aggregate）：整体与部分生命周期可以不一致，部分可以单独存在。Java 中通常通过构造器或 setter 注入。
- 继承：子类通过 extends 复用父类属性和方法，是一种白盒复用。
- 关联原则：里氏替换原则、依赖倒置原则、开闭原则与本原则关系密切，通常配合使用。

延伸阅读：

- 《敏捷软件开发：原则、模式与实践》——Robert C. Martin，组合聚合理念贯穿其中。
- 《设计模式：可复用面向对象软件的基础》——Erich Gamma 等，大量模式基于组合优于继承。
- 《Effective Java》第 18 条：优先考虑组合而不是继承。

最近又在评审代码时看到一种熟悉的味道：一个 BaseDao 被十几个子类继承，子类为了复用父类一个查询方法，被迫把连接管理、异常处理、日志打印全部继承下来；改一下父类的关闭连接逻辑，下游三个服务同时报错。我是老李。今天借这个场景，聊一个很基础但总被忽略的原则——合成聚合复用原则。为什么现在要讲？因为系统越拆越细，业务变化越来越快，用继承偷来的复用，最后都会变成技术债。

合成聚合复用原则：为什么你总把继承用成灾难，却不肯多用组合？

优先使用对象组合和聚合，而不是继承来复用代码。结合 Java 实战拆解组合、聚合的区别，带你避开继承带来的耦合陷阱。

架构师

编程语言

架构设计

后端

系统拆分越细，业务变化越快，用继承偷来的复用最终会变成技术债。合成聚合复用原则（CARP）主张用对象组合和聚合替代类继承，解决BaseDao等基类导致的耦合、封装破坏和扩展困难问题。组合通过接口定义能力，运行时动态绑定，保持类单一职责，更符合开闭原则，让代码更灵活、更易测试。

软件开发

代码解释

日志审计

短信

Java

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

合成聚合复用原则：为什么你总把继承用成灾难，却不肯多用组合？-腾讯云开发者社区-腾讯云

合成聚合复用原则：为什么你总把继承用成灾难，却不肯多用组合？

合成聚合复用原则：为什么你总把继承用成灾难，却不肯多用组合？

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐