在C++面向对象设计中，继承经常被当作代码复用的首选工具，但这种直觉并不总是正确。组合（composition）通过在一个类中嵌入其他类的对象作为成员，并借助这些成员对象完成实际功能，往往能够提供更松散的耦合和更灵活的扩展能力。准确区分继承与组合的适用边界，是编写高质量C++代码的重要前提。
很多开发者在初次接触面向对象时，会不自觉地将继承当作复用逻辑的主要方式。继承确实能够在某些层次结构中简化表达，但一旦父类发生改动，所有子类都可能受到波及。组合则通过对象之间的协作关系来复用能力，使代码更容易测试、替换和扩展。理解二者的本质差异，有助于在项目中做出更合理的设计决策。
一、继承与组合的本质差异
继承表达的是“is-a”关系，也就是子类是父类的一种特殊类型。例如，正方形可以被视为矩形的一种，这种概念上的分类关系适合用继承来建模。但继承有一个明显的问题，那就是它会打破类的封装边界。子类不仅继承了父类的公有接口，还常常需要依赖父类的实现细节。父类内部一旦调整成员变量、修改虚函数或改变构造流程，派生类就可能需要同步修改，甚至出现无法预料的编译或运行问题。
C++的public继承还会把父类的protected成员和public成员直接带入子类接口，造成接口范围膨胀。外部代码看到的子类可能远比实际需要复杂。组合则表达“has-a”或“uses-a”关系，比如汽车拥有发动机、服务持有日志对象。被组合的对象只需要保持稳定的公有接口，其内部实现变化不会影响外层类。C++中组合通过成员对象直接声明实现，编译器会按照成员声明顺序处理构造和析构，整体生命周期更容易管理。
#include <iostream>
#include <string>
class Engine {
public:
void start() {
std::cout << "引擎启动" << std::endl;
}
};
// 组合：Car 拥有 Engine
class Car {
Engine engine; // 成员对象
public:
void run() {
engine.start();
std::cout << "汽车行驶" << std::endl;
}
};
// 继承示例：如果只是单纯复用 Car，但概念上并不一定是 Car 的特例
class SportsCar : public Car {
};
从这段代码可以看出，组合方式下Car只暴露了run这个必要接口，而Engine的实现被完全封装在内部。继承方式虽然也能复用run，但SportsCar与Car之间的语义关系必须足够明确，否则继承很容易变成一种偷懒的代码复用手段。
二、优先使用组合的典型场景
当两个类之间并不存在严格的分类学上的“是一种”关系，而只是一个类需要借用另一个类的能力时，组合几乎总是更优选择。例如一个网络服务类在处理请求时需要记录日志，如果让它公开继承自Logger类，那么日志写入、日志级别控制等大量接口都会暴露给服务使用者，外部代码可能错误地调用这些本应内部使用的方法。更严重的是，如果项目未来需要更换日志库，继承结构会迫使整个服务类及其子类都受到影响。
组合的另一个优势体现在运行时灵活性。通过成员指针或智能指针注入不同实现，可以在程序运行期间替换行为。例如日志组件可以是控制台输出，也可以是文件输出，甚至可以在测试时替换为模拟对象。继承则在编译期就固定了父子关系，很难实现这种动态切换。对于需要单元测试的模块，组合能够让依赖关系通过构造函数注入，测试时传入mock对象即可隔离外部环境，而不必修改类本身。
class Logger {
public:
virtual void log(const std::string& msg) = 0;
virtual ~Logger() = default;
};
class ConsoleLogger : public Logger {
public:
void log(const std::string& msg) override {
std::cout << msg << std::endl;
}
};
class FileLogger : public Logger {
public:
void log(const std::string& msg) override {
// 实际项目中这里写入文件
}
};
// 使用组合，可在运行时注入不同日志实现
class Service {
Logger* logger; // 也可以使用智能指针管理
public:
Service(Logger* l) : logger(l) {}
void process() {
if (logger != nullptr) {
logger->log("处理开始");
}
}
};
该示例中的Service只依赖Logger的抽象接口，不关心具体的日志实现。日志策略可以在Service对象创建时决定，也可以在运行过程中替换。这种设计符合依赖倒置原则，也让测试变得更加简单直接。
三、组合带来的设计优势
组合能够显著降低模块之间的耦合度。外层类只依赖于成员对象的公有接口，不关心该对象所属的继承体系，也不关心构造函数、虚函数表等实现细节。这样在大型系统中，各个功能模块可以独立开发、独立演进。组合还能有效避免C++多重继承中的菱形继承问题、虚基类初始化复杂度，以及父类构造函数抛出异常时派生类难以处理的麻烦，因为这些复杂问题在组合模型中根本不会出现。
从代码复用角度看，组合的粒度更细、更自由。一个类可以同时组合多个功能对象，而不是沿着单一继承链获取能力。例如游戏中的角色对象可以同时拥有物理组件、渲染组件、AI组件和音频组件，每个组件负责独立的职责。这种组件化架构以组合为核心，在游戏开发和大型客户端程序中非常常见。每个组件可以被单独测试、替换或升级，而不影响角色类及其他组件。
| 对比维度 | 继承 | 组合 |
|---|---|---|
| 关系语义 | is-a | has-a / uses-a |
| 耦合程度 | 高，依赖父类实现 | 低，仅依赖接口 |
| 运行时灵活性 | 编译期固定 | 可替换成员 |
| 测试难易 | 较难隔离 | 易于注入模拟 |
当然，组合并不是完全没有代价。通过成员对象间接调用可能存在少量指针跳转或虚函数调用开销，但在绝大多数业务系统中，这种开销相比可维护性收益几乎可以忽略。只有在极端性能敏感的循环中，才需要谨慎评估组合带来的间接成本。现代C++编译器通常能够对简单成员调用进行内联优化，实际性能损失往往低于预期。
四、仍应使用继承的合理场景
继承并非一无是处。当多个类确实共享同一抽象，并且需要被统一以多态方式处理时，public继承配合虚函数是C++表达接口契约的自然方式。例如所有图形对象都可以继承自Shape基类并重写draw方法，这样渲染系统可以持有Shape*或std::unique_ptr<Shape>，不必关心具体是矩形、圆形还是三角形。这种场景下继承不仅合理，而且使代码更简洁。
另一个适合继承的情况是，子类确实需要访问父类的受保护状态，并且两者逻辑紧密绑定。例如某些框架中的模板方法模式会依赖基类定义的固定流程，子类只重写其中某些步骤。这种设计依赖于继承机制，但如果改用组合，可能需要大量转发代码才能达到相同效果。不过私有继承在C++中更多的是表达“基于某类实现”，而不是接口复用，其本质更接近组合。实践中通常建议直接用成员对象代替私有继承，因为成员对象语义更清晰，也更容易控制访问范围。
因此，在设计类之间的关系时，可以先问自己一个问题：当前这个类真的属于另一个类的特殊类型吗？如果答案是否定的，或者只是为了复用少量代码，就应当优先考虑组合。继承应当是在明确语义确认之后做出的慎重选择。
五、实践中的重构建议
如果你发现子类只使用了父类很少的方法，或者为了复用几个函数而不得不继承一个庞大的基类，这就是典型的继承滥用信号。此时应当将这些基类对象改为成员变量，把原来的继承调用改为成员调用。C++的成员初始化、委托构造以及隐式转换机制可以让这种重构比较平滑。重构后，子类不再暴露不必要的父类接口，外部依赖也会明显降低。
在组合中使用多态对象时，建议使用智能指针进行管理，例如std::unique_ptr或std::shared_ptr。这样可以避免手动管理内存带来的泄漏和悬挂指针问题。对于非多态的简单对象，则直接以值类型嵌入即可，既安全又高效。通过合理运用组合，C++代码可以更接近现代C++设计中“偏好组合、谨慎继承”的风格。
#include <memory>
class Component {
public:
virtual void update() = 0;
virtual ~Component() = default;
};
class Entity {
std::unique_ptr<Component> comp; // 使用智能指针管理多态成员
public:
Entity(std::unique_ptr<Component> c) : comp(std::move(c)) {}
void tick() {
if (comp) {
comp->update();
}
}
};
这段代码展示了组合管理多态对象的常见做法。Entity不关心Component的具体类型，只通过update接口驱动行为。构造函数接收一个std::unique_ptr<Component>，所有权转移清晰明确。这也是组合思想在实际C++项目中的典型体现：类和类之间通过稳定的接口协作，而不是通过继承关系强制绑定。
综合来看，组合解决了继承在封装性、灵活性和测试性方面的诸多痛点。继承适合表达真正稳定的类型层级，而组合适合表达对象之间的协作和功能装配。在实际开发中，优先考虑组合、在确有语义必要的时候使用继承，能够让C++代码结构更清晰、变化更容易控制，也更符合长期维护的需要。