在软件开发中，我们经常会遇到需要为现有类或对象添加额外功能或属性的场景，但又受限于不能修改原始代码。特别是当原始类是第三方库的一部分、或被设计为私有嵌套类时，挑战尤为突出。常见的解决方案如使用哈希映射（HashMap）将对象作为键，新属性作为值，虽然平均情况下能达到O(1)的检索效率，但其最坏情况可能退化到O(N)，这在对性能有严格要求的场景下是不可接受的。同时，如果原始类是一个私有嵌套类，直接通过继承来扩展其功能也变得不可行。
针对这类问题，我们可以采用以下两种设计模式，在不触及原始代码的前提下，实现O(1)最坏情况的新属性访问。
方法一：使用组合（Composition）模式
组合模式是一种强大的设计模式，它允许一个类包含另一个类的实例作为其成员。通过这种方式，我们可以在不修改原有类结构的前提下，为原有对象添加新的属性和行为。
核心思想： 创建一个新的“包装”类（例如MyVertex），该类内部包含一个原有类（例如GivenVertex）的实例，并添加我们所需的新属性。这样，MyVertex对象就拥有了GivenVertex的所有功能，并且可以直接访问其自身的新属性。
优点：
- 不修改原代码： 严格遵守了不修改原有GivenVertex代码的原则。
- O(1)检索： 新属性直接作为MyVertex的成员，访问时间复杂度为O(1)。
- 灵活性高： 即使GivenVertex是final类或其构造函数为私有（但能通过工厂方法获取实例），只要能获取到GivenVertex的实例，就可以使用此模式。
- 解耦： MyVertex与GivenVertex之间是“has-a”关系，降低了耦合度。
C++ 示例代码：
#include <iostream>
#include <cassert> // 用于断言测试
// 假设这是我们无法修改的原始顶点类
class GivenVertex {
private:
int color = 3; // 原始属性
// ... 其他原始属性或方法
public:
GivenVertex() {}
int getClr() {
return color;
}
// ... 其他原始公共方法
};
// 我们创建的新类，使用组合模式添加新属性
class MyVertex {
public:
int position; // 新增属性
GivenVertex V; // 包含原始GivenVertex的实例
// 构造函数：接受原始GivenVertex实例和新属性值
MyVertex(GivenVertex originalVertex, int newPosition) {
this->V = originalVertex;
this->position = newPosition;
}
// 可以通过MyVertex访问GivenVertex的方法
int getOriginalColor() {
return V.getClr();
}
};
int main() {
// 假设我们从某个地方获取了一个GivenVertex实例
GivenVertex originalGV = GivenVertex();
// 创建我们的MyVertex实例，并赋予新属性
int pos = 7;
MyVertex myExtendedVertex = MyVertex(originalGV, pos);
// 验证新属性和原始属性是否正确
assert(myExtendedVertex.getOriginalColor() == 3);
assert(pos == myExtendedVertex.position);
std::cout << "原始颜色: " << myExtendedVertex.getOriginalColor() << std::endl;
std::cout << "新增位置: " << myExtendedVertex.position << std::endl;
return 0;
}注意事项： 此方法要求我们能够获取到GivenVertex的实例。如果GivenVertex是一个严格意义上的私有嵌套类，且其外部类没有提供公共方法来创建或获取GivenVertex的实例，那么这种组合模式也可能面临挑战。但在大多数实际场景中，即使是嵌套类，通常也会有某种机制来暴露其实例。
方法二：使用继承（Inheritance）模式
继承模式允许一个类（子类）从另一个类（父类）继承属性和方法，并在此基础上添加新的属性和行为。
核心思想： 创建一个新的类（例如MyVertex），让它继承自原始类（GivenVertex），然后在新类中直接添加所需的额外属性。
优点：
- 不修改原代码： 同样遵守了不修改原有GivenVertex代码的原则。
- O(1)检索： 新属性直接作为MyVertex的成员，访问时间复杂度为O(1)。
- “is-a”关系： MyVertex“是”一个GivenVertex，符合面向对象设计中的“is-a”关系。
C++ 示例代码：
#include <iostream>
#include <cassert> // 用于断言测试
// 假设这是我们无法修改的原始顶点类
// 注意：为了继承，GivenVertex不能是private nested class，且其方法需要能被子类访问
class GivenVertex {
private:
int color = 3;
public:
GivenVertex() {}
// 为了让子类能访问，getGivenClr()需要是public或protected
int getGivenClr() {
return color;
}
};
// 我们创建的新类，使用继承模式添加新属性
// 注意：如果GivenVertex是private nested class，这里将无法直接继承
class MyVertex : private GivenVertex { // 示例中使用private继承，也可以是public
public:
int position; // 新增属性
// 构造函数：初始化新属性
MyVertex(int newPosition) {
this->position = newPosition;
}
// 可以通过MyVertex访问继承来的方法
int getMyClr() {
return getGivenClr(); // 访问父类的公共或保护方法
}
};
int main() {
// 创建MyVertex实例，它同时拥有GivenVertex的属性和新属性
int pos = 7;
MyVertex myExtendedVertex = MyVertex(pos);
// 验证新属性和继承来的原始属性是否正确
assert(myExtendedVertex.getMyClr() == 3);
assert(pos == myExtendedVertex.position);
std::cout << "继承颜色: " << myExtendedVertex.getMyClr() << std::endl;
std::cout << "新增位置: " << myExtendedVertex.position << std::endl;
return 0;
}注意事项与选择： 继承模式的适用性受到原始类GivenVertex设计的严格限制：
- 访问修饰符： 如果GivenVertex确实是一个private nested class，那么它在外部是不可见的，也就无法直接被继承。此示例代码为了演示继承，将GivenVertex视为一个可继承的独立类。
- 方法可见性： 如果GivenVertex的有用方法是private的，即使继承了也无法直接访问。
- final类： 如果GivenVertex被声明为final（在Java中）或在C++中没有虚函数且其构造函数复杂，也可能阻碍继承。
组合与继承的比较： | 特性 | 组合（Composition）模式 | 继承（Inheritance）模式 | | :----------- | :----------------------------------------------------- | :---------------------------------------------------------- | | 关系 | “has-a”（拥有一个），例如MyVertex“拥有”一个GivenVertex | “is-a”（是一个），例如MyVertex“是一个”GivenVertex | | 灵活性 | 更高，对原有类依赖较小，即使原类final或构造器私有也可使用 | 较低，受限于原有类的访问修饰符、是否final等，耦合度较高 | | 适用场景 | 当无法继承或不希望建立强继承关系时；当原类实例可获取时 | 当原类可被继承，且新类确实是原类的一种特殊类型时 | | 复杂性 | 需要通过包装类来委托调用原有类的方法 | 直接访问继承来的方法，代码可能更简洁 |
总结
在不修改原有代码的前提下为对象添加新属性并确保O(1)最坏情况检索，组合模式和继承模式是两种有效的策略。
- 组合模式更加灵活和通用，尤其适用于原始类是final、或其内部结构复杂、或作为私有嵌套类但其外部类提供了获取实例的方法等场景。它通过“拥有”一个原始对象来扩展功能。
- 继承模式则更符合面向对象的“is-a”关系，但它对原始类的设计有更高的要求，即原始类必须是可继承且其关键方法可访问。如果原始类严格是private nested class，通常无法直接采用继承。
在实际开发中，应根据原始类的具体实现和访问权限来选择最合适的策略。当继承不可行或不合适时，组合模式往往是更稳健的选择。
