公开类拥有的资源的正确方法是什么？

Question

假设我有一个库，它有一个 Document 类。 Document 的一个实例可以拥有多个Field 实例。 Field 有多个子类（例如IntegerField 和StringField），甚至API 用户也可以对其进行子类化，并将子类实例提供给Document（假设用户可以开发自定义类型的数据来存储在字段中）。

我想通过 API 公开Document 拥有的Field 实例，以便用户可以与它们交互，但不转移所有权。

这样做的正确方法是什么？

我想过：

• 暴露 const std::unique_ptr<Field>& 引用 - 这感觉很丑
• 暴露一个普通的 Field* 指针 - 这感觉不对，因为用户可能不确定是否应该删除该实例
• 改用std::shared_ptr - 这感觉很糟糕，因为所有权并未真正共享

例如，

class Document {
private:
    std::map<std::string, std::unique_ptr<Field> > fields;
    // ...
public:
    // ...

    // How is this done properly?
    const std::unique_ptr<Field> &field(const std::string &name) {
        return fields[name];
    }
}

期待您的建议。
（我也欢迎有关 @Fulvio 建议的替代方法的建议。）

Answer 1

我通常返回对数据的引用而不是对unique_ptr的引用：

const Bar &getBar(std::string name) const {
    return *bars[name];
}

如果您希望能够返回空项目，您可以返回原始指针（如果为空，则返回 nullptr）。或者更好的是你可以使用boost::optional（C++14 中的std::optional）。

如果引用的存在时间可能比所有者长（多线程环境），我在内部使用 shared_ptr 并在访问方法中返回 weak_ptr。

Answer 2

如果可能的话，我会尽量避免暴露Document 的内部结构，但如果失败，我将返回const Field&，或者如果您需要它可以为空，则返回const Field*。两者都清楚地表明Document 保留所有权。另外，将方法本身设为const。

您可以使用返回 Field& 或 Field* 的方法的非 const 版本，但如果可以的话，我会避免这样做。

Answer 3

这还没有考虑，我猜：返回一个具有相同接口的代理对象。

代理对象的持有者拥有该代理对象的所有权。 代理持有对被引用对象的任何引用（可能很弱）。 删除对象后，您可能会引发一些错误。 代理对象没有所有权。

也许已经提到过。我对 C++ 不是很熟悉。

Answer 4

我通常不喜欢将参考资料交给内部成员。如果另一个线程修改它会发生什么？相反，如果我不能分发副本，我更喜欢更实用的方法。像这样。

class Foo {
private:
    std::map<std::string, std::unique_ptr<Bar> > bars;

    // ...

public:

    // ...
    template<typename Callable> void withBar(const std::string& name, Callable call) const {
        //maybe a lock_guard here?
        auto iter = bars.find(name);
        if(iter != std::end(bars)) {
            call(iter->second.get());
        }
    }
}

这样，拥有的内部永远不会“离开”拥有它的类，并且所有者可以控制不变量。如果请求的条目不存在，也可以有一些细节，比如使代码成为 noop。可以这样用，

myfoo.withBar("test", [] (const Bar* bar){
   bar->dostuff();
});

Answer 5

正如其他人从技术角度回答的那样，我想向您指出一种不同的方法并修改您的设计。这个想法是尽量尊重the Law of Demeter，并且不授予对对象子组件的访问权限。这有点难做，没有具体的例子，我无法提供很多细节，但试着想象一个由 Pages 组成的类 Book。如果我想用您当前的设计打印一页、两页或更多页的书，我可以这样做：

auto range = ...;
for( auto p : book.pages(range) )
  {
  p->print();
  }

在遵守得墨忒耳的同时，你将拥有

auto range = ...;
book.print( /* possibly a range here */ );

这倾向于更好的封装，因为您不依赖 book 类的内部细节，并且如果其内部结构发生变化，您无需对客户端代码执行任何操作。

Answer 6

我会返回 std::weak_ptr< Bar >（如果 C++11）或 boost::weak_ptr（如果不是 C++11）。这清楚地表明这是堆内存，并且不会冒对不存在内存的引用的风险（就像Bar & 一样）。它还明确了所有权。

Answer 7

我会返回Bar&（可能带有const）。

用户需要了解，如果从地图中删除元素，则引用将失效 - 但由于单一所有权模型，无论您做什么，都会出现这种情况。