聚合与组合是面向对象设计中描述对象之间整体与部分关系的两种核心关联类型。很多初学者在阅读UML类图时，会看到空心菱形代表聚合，实心菱形代表组合，却并不清楚这两种菱形在代码层面和运行时行为上的本质区别。简单来说，聚合（Aggregation）表示一种“弱拥有”关系，整体对象可以包含部分对象，但部分对象并不依赖整体对象的生命周期；组合（Composition）则表示一种“强拥有”关系，部分对象是整体对象的固有组成部分，一旦整体对象被销毁，部分对象也必须随之销毁。这种语义差异在管理全局系统变量、配置信息、服务实例等资源时尤为关键，因为错误的关联类型会导致内存泄漏、悬挂指针或对象状态不一致。
以一个典型的系统配置管理器为例，假设有一个SystemConfig对象保存着数据库连接字符串、日志级别等全局变量。如果这些变量是简单的字符串或数字，它们以值类型的方式直接存储在SystemConfig内部，这天然属于组合关系——配置对象的销毁就意味着这些变量的销毁。但如果SystemConfig持有的是另一个独立服务，比如一个Logger实例或DatabasePool实例，并且这个实例可能被其他模块共享，那么SystemConfig与这些服务之间就是聚合关系。理解这一点是正确管理变量生命周期的基础。
聚合与组合的语义边界
聚合和组合最根本的区别在于“所有权”的强度。组合关系下，容器对象对内部对象拥有排他性的所有权，内部对象不存在独立于容器之外的业务意义。例如，一个Car对象由Engine、Wheel、Seat等组成，当Car被销毁时，这些组件没有理由继续存在——它们无法脱离具体的汽车而单独发挥功能。在C++中，组合通常通过直接包含对象成员来实现：
class Engine {
public:
Engine() { /* 初始化发动机 */ }
~Engine() { /* 释放发动机资源 */ }
};
class Car {
private:
Engine engine; // 组合：Engine对象是Car的一部分
Wheel wheels[4]; // 组合：四个轮子直接内嵌
public:
Car() : engine(), wheels{} { }
// 无需显式析构engine和wheels，Car析构时会自动调用它们的析构函数
};
上面的代码中，Engine和Wheel对象的内存空间直接分配在Car对象内部，它们的生命周期与Car完全同步。这种组合关系在内存布局上非常紧凑，也不存在单独销毁子对象的风险。相比之下，聚合关系则通过指针、引用或共享指针来实现，被聚合对象的生命周期由外部管理。
聚合的典型特征是“部分可以离开整体而独立存在”。例如，一个University对象可以包含多个Student对象，但学生并不因为大学的销毁而消失，他们只是与大学解除关联。在代码中，聚合通常表现为容器持有指向外部对象的指针或引用，容器并不负责这些对象的创建和销毁。比如使用原始指针时：
class Student {
public:
Student(const std::string& name) : name_(name) {}
const std::string& getName() const { return name_; }
private:
std::string name_;
};
class University {
private:
std::vector<Student*> students; // 聚合：仅保存指针，不拥有Student对象
public:
void enroll(Student* s) {
students.push_back(s);
}
// University析构时不会delete这些Student指针，因为学生仍可能被其他大学或社团引用
};
这种聚合实现要求调用方保证Student对象在University使用期间一直有效。如果Student对象在University之前被销毁，University内部就会产生悬挂指针。现代C++推荐使用std::shared_ptr或std::weak_ptr来表达聚合，以降低这种风险，但即使使用共享指针，语义上仍然是聚合——因为University并不拥有Student的独占所有权，多个容器可以共享同一个学生。
系统变量生命周期管理的差异
系统变量通常指那些在应用程序运行期间全局存在、被多个模块访问的配置值或服务实例。根据变量与容器之间的关系不同，管理策略也必须调整。如果系统变量是组合关系的一部分，那么它的创建和销毁应当完全由包含它的对象负责，外部代码不应干预。例如，一个SessionManager内部创建一个SessionCache对象，这个缓存只服务于当前会话管理器，当会话管理器销毁时，缓存也必须被同步销毁：
public class SessionManager {
// 组合：cache对象由SessionManager独占创建和销毁
private final SessionCache cache = new SessionCache();
public SessionManager() {
cache.initialize();
}
public void close() {
cache.clear();
// 不需要显式置null，因为cache随SessionManager一起被回收
}
}
这里SessionCache的生命周期被严格限制在SessionManager内部。如果外部代码试图直接操作cache的销毁，就会破坏组合语义，引发对象状态不一致。相反，如果系统变量是一个被多个模块共享的全局服务，比如日志记录器Logger，它通常表现为聚合关系。多个业务模块都持有对Logger的引用，但没有任何一个模块能够独占销毁它，因为其他模块可能还在使用。这种情况下，Logger的生命周期应该由专门的容器或框架来管理，而不是由某一个业务对象负责。
在实际项目里，混淆这两种关系最常见的后果就是生命周期错配。例如，开发者在一个Application类中用成员变量的方式直接内嵌了一个DatabaseConnectionPool对象（组合），但同时又希望其他模块能够独立获取这个连接池的引用以便执行查询。当Application对象因为某种原因被提前释放时，连接池被析构，其他模块持有的引用全部失效，导致运行时崩溃。正确的做法应该是让DatabaseConnectionPool成为一个独立的全局服务，Application与其他模块都通过聚合关系引用它，由专门的ServiceLocator或依赖注入容器来管理其生命周期。
实战：设计一个清晰的生命周期容器
为了系统化地管理聚合与组合变量，我们可以设计一个简单的ComponentContainer，它区分两种注册方式：registerComposed用于注册组合型对象（由容器负责销毁），registerAggregated用于注册聚合型对象（仅保存引用，不负责销毁）。这样可以让生命周期意图在代码中显式化。
#include <memory>
#include <unordered_map>
#include <string>
#include <functional>
#include <stdexcept>
class Component {
public:
virtual ~Component() = default;
};
class ComponentContainer {
private:
// 组合关系：容器独占所有权，析构时自动销毁
std::unordered_map<std::string, std::unique_ptr<Component>> composed_;
// 聚合关系：容器仅保存裸指针，不管理生命周期
std::unordered_map<std::string, Component*> aggregated_;
public:
template<typename T, typename... Args>
T* registerComposed(const std::string& key, Args&&... args) {
auto ptr = std::make_unique<T>(std::forward<Args>(args)...);
T* raw = ptr.get();
composed_.emplace(key, std::move(ptr));
return raw;
}
void registerAggregated(const std::string& key, Component* obj) {
if (obj == nullptr) {
throw std::invalid_argument("Aggregated component cannot be null");
}
aggregated_[key] = obj;
}
Component* get(const std::string& key) const {
auto cit = composed_.find(key);
if (cit != composed_.end()) return cit->second.get();
auto ait = aggregated_.find(key);
if (ait != aggregated_.end()) return ait->second;
throw std::runtime_error("Component not found: " + key);
}
// 析构时：unique_ptr自动销毁组合对象；聚合对象的指针不执行delete
~ComponentContainer() = default;
};
这个容器的核心思想是把“所有权”和“访问权”分离。组合对象通过unique_ptr存储，容器析构时自动调用delete；聚合对象仅存放原始指针，容器不干预其生命周期，但提供统一的访问接口get()。使用这个容器，开发者可以在注册时明确表达变量与容器之间的关系，避免出现隐式的生命周期假设。例如，系统配置中的日志级别是一个值类型，直接内嵌即可；而日志记录器服务则通过registerAggregated注入，由外部框架负责销毁。
在更大规模的系统中，这种显式生命周期管理可以通过依赖注入（DI）框架来实现。Spring框架中的@Scope("prototype")与@Scope("singleton")虽然侧重于实例化策略，但也可以映射到聚合与组合的思维：单例Bean由容器完全管理（类似组合，容器负责销毁），原型Bean每次注入新实例（调用方承担生命周期责任，类似聚合）。不过需要注意，原型Bean并不等同于聚合，因为聚合强调的是部分可以独立于整体存在，而原型Bean的生命周期仍然可能由容器追踪。理解这些细微差别有助于设计出更健壮的系统变量管理方案。
选择关系类型时的常见误区
第一个常见误区是把所有“包含”关系都实现为组合。有些开发者看到类A里面有一个类B的成员变量，就默认使用组合，即使B在业务上可能是一个独立的服务或实体。这种过度组合会导致不必要的耦合和资源浪费。例如，一个Order类包含一个Customer对象，但Customer显然不应该随着Order的销毁而消失，因为同一个客户可能有多个订单。如果Order内嵌了Customer的副本，不仅浪费内存，还可能导致数据不一致——修改Order内部的Customer副本不会影响数据库中的真实客户记录。这里Order与Customer应该是聚合关系，Order保存Customer的唯一标识或引用即可。
第二个误区是误用聚合来实现本应组合的关系，导致资源泄漏。典型的例子是使用std::vector<T*>来管理内部动态创建的对象，但忘记在析构时释放这些指针。开发者的本意可能是“这个vector拥有这些对象”，但使用裸指针并没有体现所有权，代码阅读者无法确定是否需要手动删除。现代C++的做法是使用std::vector<std::unique_ptr<T>>来明确表达组合关系，或者使用std::vector<std::shared_ptr<T>>表达共享所有权的聚合。如果坚持使用裸指针，则必须在文档和命名中明确说明容器是否拥有所指对象，例如将成员命名为owned_students_和observed_students_加以区分。
第三个误区是在多线程环境下忽略聚合对象的生命周期同步。聚合关系允许外部对象独立存在，但这意味着外部对象可能在任意时间被其他线程销毁，而持有聚合引用的线程并未察觉。解决这种问题不能简单依赖组合关系，因为组合会引入不必要的耦合。正确做法是使用std::shared_ptr与std::weak_ptr配合，让聚合方持有weak_ptr，在访问时通过lock()检查对象是否仍然存活。这种模式既保留了聚合的灵活性，又避免了悬挂引用，是管理系统变量生命周期时非常实用的技术。
聚合与组合的选择本质上是对“所有权语义”的明确表达。在系统变量生命周期管理中，如果变量是某个模块私有的、不可共享的，就应该使用组合，让编译器或容器自动管理销毁；如果变量是全局共享的、跨模块使用的，就应该使用聚合，并引入专门的生命周期管理器。显式区分这两种关系，可以大幅减少资源管理错误，提升代码的可维护性和可读性。