干净的 C++细粒度的朋友相当于？ （答案：律师-委托人习语）

Question

为什么 C++ 具有任何人都可以调用的 public 成员以及将所有 private 成员公开给 的 friend 声明给出了外部类或方法，但没有提供向给定调用者公开特定成员的语法？

我想用一些例程来表达接口，这些例程只能由已知的调用者调用，而不必授予这些调用者对所有私有变量的完全访问权限，这感觉像是一个合理的事情。到目前为止，我自己能想到的最好的（如下）和其他人的建议都围绕着不同间接性的习语/模式，我真的只是想要一种方法来拥有单一，明确指示的简单类定义哪些调用者（比我、我的孩子或绝对任何人更精细）可以访问哪些成员。表达以下概念的最佳方式是什么？

// Can I grant Y::usesX(...) selective X::restricted(...) access more cleanly?
void Y::usesX(int n, X *x, int m) {
  X::AttorneyY::restricted(*x, n);
}

struct X {
  class AttorneyY;          // Proxies restricted state to part or all of Y.
private:
  void restricted(int);     // Something preferably selectively available.
  friend class AttorneyY;   // Give trusted member class private access.
  int personal_;            // Truly private state ...
};

// Single abstract permission.  Can add more friends or forwards.
class X::AttorneyY {
  friend void Y::usesX(int, X *, int);
  inline static void restricted(X &x, int n) { x.restricted(n); }
};

我距离软件组织大师还差得远，但感觉界面简单性和最小权限原则在语言的这方面是直接矛盾的。对于我的愿望，一个更清晰的例子可能是一个带有声明方法的 Person 类，例如 takePill(Medicine *) tellTheTruth() 和 forfeitDollars( unsigned int) ，只有 Physician、Judge 或 TaxMan 实例/成员方法才应该考虑调用。每个主要接口方面都需要一次性代理或接口类，这让我感到不舒服，但如果您知道我遗漏了一些东西，请大声说出来。

从Drew Hall接受的答案：Dr Dobbs - 友谊和律师-客户习惯用法

上面的代码最初将包装类称为“代理”而不是“律师”，并使用指针而不是引用，但后来否则相当于德鲁发现的，然后我认为这是最好的众所周知的解决方案。 （不要太用力地夸奖自己......）我还更改了“restricted”的签名来演示参数转发。此习惯用法的总体成本是每个权限集一个类和一个朋友声明、每个经过批准的调用者集一个朋友声明以及每个权限集每个公开方法一个转发包装器。下面大部分更好的讨论都围绕着转发调用样板，一个非常相似的“Key”习惯用法以较少的直接保护为代价避免了该样板。

Answer 1

有一个非常简单的模式，被追溯称为 PassKey，在 C++11 中非常简单：

template <typename T>
class Key { friend T; Key() {} Key(Key const&) {} };

以及

class Foo;

class Bar { public: void special(int a, Key<Foo>); };

调用站点，在任何 Foo 方法中，看起来像：

Bar().special(1, {});

注意：如果您陷入 C++03，请跳到帖子末尾。

代码看似简单，它包含了一些值得详细阐述的关键点。

该模式的关键在于：

• 调用 Bar::special 需要在调用者的上下文中复制 Key，
• 只有 Foo 可以构造或复制 Key

值得注意的是：

• 从 Foo 派生的类不能构造或复制 Key 因为友谊不是及物
• Foo 本身无法传递 Key 供任何人调用 Bar::special，因为调用它不仅需要持有 因为 C++ 是 C++，所以

需要避免一些问题：

• 复制构造函数必须是用户定义的，否则默认情况下它是 public 默认
• 构造函数必须是用户定义的已定义，否则默认为 public 默认
• 构造函数必须手动定义，因为 = default 将允许聚合初始化绕过手动用户- 定义的默认构造函数（从而允许任何类型获取实例）

这非常微妙，我建议您逐字复制/粘贴上面的 Key 定义，而不是尝试重现它从记忆中。

---

允许委托的变体：

class Bar { public: void special(int a, Key<Foo> const&); };

在此变体中，任何拥有 Key 实例的人都可以调用 Bar::special，因此即使只有 Foo > 可以创建一个Key，然后它可以将凭证传播给可信的副手。

在此变体中，为了避免流氓中尉泄漏密钥，可以完全删除复制构造函数，这允许将密钥生命周期绑定到特定的词法范围。

---

那么在 C++03 中呢？

嗯，这个想法是相似的，除了 friend T; 不是一个东西，所以必须为每个持有者创建一个新的密钥类型：

class KeyFoo { friend class Foo; KeyFoo () {} KeyFoo (KeyFoo const&) {} };

class Bar { public: void special(int a, KeyFoo); };

该模式足够重复，可能值得一个宏来避免拼写错误。

聚合初始化不是问题，但 = default 语法也不可用。

---

特别感谢多年来帮助改进这个答案的人：

• Luc Touraille，在评论中指出我class KeyFoo: boost::noncopyable { 朋友类 Foo; KeyFoo() {} }; 完全禁用复制构造函数，因此仅适用于委托变体（防止存储实例）。
• K-ballo，指出 C+ 如何+11 改善了与朋友 T 的情况；

Answer 2

律师-客户惯用语可能就是您正在寻找的。该机制与您的成员代理类解决方案没有太大不同，但这种方式更惯用。

Answer 3

我知道这是一个老问题，但问题仍然相关。虽然我喜欢“律师-客户”习惯用法的想法，但我希望为已被授予私有（或受保护）访问权限的客户类提供一个透明的接口。

我想类似的事情已经完成了，但粗略地环顾四周并没有发现任何东西。以下方法 (C++11 up) 在每个类（而不是每个对象）的基础上工作，并使用“私有类”使用的 CRTP 基类来公开公共函子。只有那些被专门授予访问权限的类才能调用函子的operator()，然后它通过存储的引用直接调用关联的私有方法。

没有函数调用开销，唯一的内存开销是每个需要公开的私有方法的一个引用。该系统用途广泛；任何函数签名和返回类型都是允许的，就像在私有类中调用虚函数一样。

对我来说，主要的好处之一是语法。虽然私有类中需要对仿函数对象进行相当难看的声明，但这对于客户端类来说是完全透明的。下面是一个取自原始问题的示例：

struct Doctor; struct Judge; struct TaxMan; struct TheState;
struct Medicine {} meds;

class Person : private GranularPrivacy<Person>
{
private:
    int32_t money_;
    void _takePill (Medicine *meds) {std::cout << "yum..."<<std::endl;}
    std::string _tellTruth () {return "will do";}
    int32_t _payDollars (uint32_t amount) {money_ -= amount; return money_;}

public:
    Person () : takePill (*this), tellTruth (*this), payDollars(*this) {}

    Signature <void, Medicine *>
        ::Function <&Person::_takePill>
            ::Allow <Doctor, TheState> takePill;

    Signature <std::string>
        ::Function <&Person::_tellTruth>
            ::Allow <Judge, TheState> tellTruth;

    Signature <int32_t, uint32_t>
        ::Function <&Person::_payDollars>
            ::Allow <TaxMan, TheState> payDollars;

};


struct Doctor
{
    Doctor (Person &patient)
    {
        patient.takePill(&meds);
//        std::cout << patient.tellTruth();     //Not allowed
    }
};

struct Judge
{
    Judge (Person &defendant)
    {
//        defendant.payDollars (20);            //Not allowed
        std::cout << defendant.tellTruth() <<std::endl;
    }
};

struct TheState
{
    TheState (Person &citizen)                  //Can access everything!
    {
        citizen.takePill(&meds);
        std::cout << citizen.tellTruth()<<std::endl;
        citizen.payDollars(50000);
    };
};

GranularPrivacy 基类通过定义 3 个嵌套模板类来工作。其中第一个“Signature”将函数返回类型和函数签名作为模板参数，并将它们转发给函子的operator() 方法和第二个嵌套模板类“Function”。这是通过指向 Host 类的私有成员函数的指针来参数化的，该函数必须具有 Signature 类提供的签名。在实践中，使用两个单独的“函数”类；此处给出的一个，以及 const 函数的另一个，为简洁起见，省略了。

最后，Allow 类使用可变参数模板机制从显式实例化的基类递归继承，具体取决于其模板参数列表中指定的类的数量。 Allow 的每个继承级别都有一个来自模板列表的友元，并且 using 语句将基类构造函数和运算符 () 沿继承层次结构向上带到最派生的范围。

template <class Host> class GranularPrivacy        
{
    friend Host;
    template <typename ReturnType, typename ...Args> class Signature
    {
        friend Host;
        typedef ReturnType (Host::*FunctionPtr) (Args... args);
        template <FunctionPtr function> class Function
        {
            friend Host;
            template <class ...Friends> class Allow
            {
                Host &host_;
            protected:
                Allow (Host &host) : host_ (host) {}
                ReturnType operator () (Args... args) {return (host_.*function)(args...);}
            };
            template <class Friend, class ...Friends>
            class Allow <Friend, Friends...> : public Allow <Friends...>
            {
                friend Friend;
                friend Host;
            protected:
                using Allow <Friends...>::Allow;
                using Allow <Friends...>::operator ();
            };
        };
    };
};

我希望有人觉得这很有用，任何意见或建议都将受到欢迎。这肯定仍在进行中 - 我特别想将 Signature 和 Function 类合并到一个模板类中，但一直在努力寻找一种方法来做到这一点。更完整、可运行的示例可以在 cpp.sh/6ev45 和 cpp.sh/2rtrj。

Answer 4

您可以使用 Jeff Aldger 的书“真正程序员的 C++”中描述的模式。它没有特殊的名称，但被称为“宝石和刻面”。基本思想如下：在包含所有逻辑的主类中，定义几个实现该逻辑子部分的接口（不是真正的接口，只是像它们一样）。每个接口（书中的方面）都提供对主类（gemstone）的一些逻辑的访问。此外，每个方面都保存着指向宝石实例的指针。

这对你来说意味着什么？

1. 您可以在任何地方使用任何刻面而不是宝石。
2. 刻面的用户不必了解宝石结构，因为可以通过 PIMPL 模式进行前向声明和使用。
3. 其他类可以引用facet而不是gemstone - 这是关于如何向指定类公开有限数量的方法的问题的答案。

希望这有帮助。如果您愿意，我可以在此处发布代码示例以更清楚地说明此模式。

编辑：这是代码：

class Foo1; // This is all the client knows about Foo1
class PFoo1 { 
private: 
 Foo1* foo; 
public: 
 PFoo1(); 
 PFoo1(const PFoo1& pf); 
 ~PFoo(); 
 PFoo1& operator=(const PFoo1& pf); 

 void DoSomething(); 
 void DoSomethingElse(); 
}; 
class Foo1 { 
friend class PFoo1; 
protected: 
 Foo1(); 
public: 
 void DoSomething(); 
 void DoSomethingElse(); 
}; 

PFoo1::PFoo1() : foo(new Foo1) 
{} 

PFoo1::PFoo(const PFoo1& pf) : foo(new Foo1(*(pf
{} 

PFoo1::~PFoo() 
{ 
 delete foo; 
} 

PFoo1& PFoo1::operator=(const PFoo1& pf) 
{ 
 if (this != &pf) { 
  delete foo; 
  foo = new Foo1(*(pf.foo)); 
 } 
 return *this; 
} 

void PFoo1::DoSomething() 
{ 
 foo->DoSomething(); 
} 

void PFoo1::DoSomethingElse() 
{ 
 foo->DoSomethingElse(); 
} 

Foo1::Foo1() 
{ 
} 

void Foo1::DoSomething() 
{ 
 cout << “Foo::DoSomething()” << endl; 
} 

void Foo1::DoSomethingElse() 
{ 
 cout << “Foo::DoSomethingElse()” << endl; 
} 

编辑2：
您的类 Foo1 可能更复杂，例如，它包含另外两个方法：

void Foo1::DoAnotherThing() 
{ 
 cout << “Foo::DoAnotherThing()” << endl; 
} 

void Foo1::AndYetAnother() 
{ 
 cout << “Foo::AndYetAnother()” << endl; 
} 

并且可以通过 class PFoo2 访问它们

class PFoo2 { 
    private: 
     Foo1* foo; 
    public: 
     PFoo2(); 
     PFoo2(const PFoo1& pf); 
     ~PFoo(); 
     PFoo2& operator=(const PFoo2& pf); 

     void DoAnotherThing(); 
     void AndYetAnother(); 
    };
void PFoo1::DoAnotherThing() 
    { 
     foo->DoAnotherThing(); 
    } 

    void PFoo1::AndYetAnother() 
    { 
     foo->AndYetAnother(); 
    } 

这些方法不在 PFoo1 类中，因此您不能通过它访问它们。通过这种方式，您可以将 Foo1 的行为拆分为两个（或更多）方面 PFoo1 和 PFoo2。这些方面类可以在不同的地方使用，并且它们的调用者不应该知道 Foo1 实现。也许这不是你真正想要的，但你想要的对于 C++ 来说是不可能的，这是一个解决方法，但可能太冗长了......

Answer 5

类似于下面的代码，您可以通过 friend 关键字对私有状态的哪些部分进行精细控制。

class X {
  class SomewhatPrivate {
    friend class YProxy1;

    void restricted();
  };

public:
  ...

  SomewhatPrivate &get_somewhat_private_parts() {
    return priv_;
  }

private:
  int n_;
  SomewhatPrivate priv_;
};

但是：

1. 我认为这不值得付出努力。
2. 需要使用 friend 关键字可能表明您的设计存在缺陷，也许有一种方法可以在没有它的情况下完成您需要的操作。我试图避免它，但如果它使代码更具可读性、可维护性或减少对样板代码的需求，我就会使用它。

编辑：对我来说，上面的代码（通常）是令人厌恶的，应该（通常）不使用。

Answer 6

我对 Matthieu M 给出的解决方案做了一个小小的改进。他的解决方案的局限性是您只能授予对单个类的访问权限。如果我想让三个类中的任何一个具有访问权限怎么办？

#include <type_traits>
#include <utility>

struct force_non_aggregate {};

template<typename... Ts>
struct restrict_access_to : private force_non_aggregate {
    template<typename T, typename = typename std::enable_if<(... or std::is_same<std::decay_t<T>, std::decay_t<Ts>>{})>::type>
    constexpr restrict_access_to(restrict_access_to<T>) noexcept {}
    restrict_access_to() = delete;
    restrict_access_to(restrict_access_to const &) = delete;
    restrict_access_to(restrict_access_to &&) = delete;
};

template<typename T>
struct access_requester;

template<typename T>
struct restrict_access_to<T> : private force_non_aggregate {
private:
    friend T;
    friend access_requester<T>;

    restrict_access_to() = default;
    restrict_access_to(restrict_access_to const &) = default;
    restrict_access_to(restrict_access_to &&) = default;
};

// This intermediate class gives us nice names for both sides of the access
template<typename T>
struct access_requester {
    static constexpr auto request_access_as = restrict_access_to<T>{};
};


template<typename T>
constexpr auto const & request_access_as = access_requester<T>::request_access_as;

struct S;
struct T;

auto f(restrict_access_to<S, T>) {}
auto g(restrict_access_to<S> x) {
    static_cast<void>(x);
    // f(x); // Does not compile
}

struct S {
    S() {
        g(request_access_as<S>);
        g({});
        f(request_access_as<S>);
        // f(request_access_as<T>); // Does not compile
        // f({request_access_as<T>});   // Does not compile
    }
};

struct T {
    T() {
        f({request_access_as<T>});
        // g({request_access_as<T>}); // Does not compile
        // g({}); // Does not compile
    }
};

这使用了稍微不同的方法来使对象不是聚合。我们没有用户提供的构造函数，而是有一个空的私有基类。在实践中，这可能并不重要，但这意味着这个实现是一个 POD 类，因为它仍然很琐碎。然而，效果应该保持不变，因为无论如何没有人会存储这些对象。