C++接口声明难题：返回对象向量还是对象指针向量

问题背景 #

我们需要设计一个通用的范围搜索接口，要求支持添加值、获取可修改的存储值、范围查询三个核心功能。最初的接口定义如下：

template <typename T>
class RangeSearchInterface // 省略虚析构、移动构造等
{
public:
    virtual void Add(const T & value) = 0;
    virtual std::vector<T> & Get() = 0;
    virtual std::vector<T *> & RangeQuery(const T & value) = 0;
};

但在实现暴力搜索和分块优化两种算法时，出现了明显的矛盾：

• 暴力搜索可以直接返回存储的对象向量，完全符合接口要求；
• 分块算法实现Get()时，返回对象向量会产生冗余拷贝，且修改返回的向量不会影响内部存储（因为是拷贝），而返回指针向量更高效；
• 如果修改接口为返回指针向量，暴力搜索则需要额外生成指针向量，带来不必要的性能开销。

延伸到只读场景，同样存在返回const std::vector<T>&还是const std::vector<const T*>&的两难选择。

问题解答 #

1. 如何抉择返回对象向量还是对象指针向量？ #

没有绝对的标准答案，核心是平衡语义一致性、性能和易用性：

• 优先看接口的核心语义：如果接口的定位是让用户直接操作存储的实体对象，且多数实现（比如暴力搜索）能高效返回对象引用，那优先保留对象向量的返回类型；如果多数实现更适合用指针管理元素（比如分块、树结构），或者用户需要的是对对象的间接访问，就选择指针向量。
• 性能与易用性权衡：对象向量无需用户管理指针，更安全易用，但分块这类实现会有拷贝或无效修改的问题；指针向量性能更优，但暴力实现要额外生成指针，用户还要承担空指针、野指针的风险。
• 只读场景可以提供双选项：同时提供const std::vector<T>& Get() const和const std::vector<const T*>& GetPointers() const，让用户根据自己的性能需求和使用场景选择。

2. 针对这类场景设计接口是否有价值？ #

有价值，但要明确接口的定位和适用范围：

• 核心价值是统一算法的调用方式：上层业务代码可以无缝切换不同的搜索算法（暴力、分块、线段树等），无需修改业务逻辑，降低了算法替换的成本。
• 但要避免过度抽象：如果接口的约束导致所有实现都要付出额外的性能或维护成本（比如暴力实现要生成指针，分块实现要拷贝对象），这种抽象的价值就会大打折扣，此时需要重新评估是否真的需要统一接口，还是让不同算法各自暴露接口。

3. 如何从设计源头避免陷入此类困境？ #

可以从以下几个方向优化接口设计：

• 用迭代器/视图替代容器返回：不要强制返回特定类型的容器，而是提供迭代器范围或视图，让每个实现可以用最适合自己的方式提供访问能力。比如：

  template <typename T>
  class RangeSearchInterface {
  public:
      virtual void Add(const T& value) = 0;
      
      // 提供迭代器接口，而非直接返回vector
      virtual auto begin() -> typename std::vector<T>::iterator = 0;
      virtual auto end() -> typename std::vector<T>::iterator = 0;
      virtual auto begin() const -> typename std::vector<T>::const_iterator = 0;
      virtual auto end() const -> typename std::vector<T>::const_iterator = 0;
      
      // RangeQuery返回迭代器范围，而非指针vector
      virtual auto RangeQuery(const T& value) -> std::pair<typename std::vector<T>::iterator, typename std::vector<T>::iterator> = 0;
  };
  

  分块实现可以自定义迭代器来遍历分散的块元素，避免容器类型的冲突。C++20及以上还可以用std::span或范围视图（std::ranges::view）来进一步简化。
• 拆分接口职责：把添加、读取、查询拆成独立的小接口，比如Addable<T>、Iterable<T>、RangeQueryable<T>，让实现类按需继承，避免强制所有实现支持不适合的操作。
• 明确值语义与引用语义：在设计接口前先确定内部存储的是值还是指针，以此统一接口的返回类型。比如内部存储值就暴露值的访问方式，内部存储指针就暴露指针的访问方式，避免混合语义导致的矛盾。

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