如何在 C++ 中伪造“类的可见性”（而不是函数的可见性）？

Question

有no feature that control visibility/accessibility of class in C++。

有没有办法伪造它？
是否有任何可以模拟最接近行为的 C++ 宏/模板/魔术？

情况是这样的

Util.h（库）

class Util{   
    //note: by design, this Util is useful only for B and C
    //Other classes should not even see "Util"
    public: static void calculate(); //implementation in Util.cpp
};

B.h（库）

#include "Util.h"
class B{ /* ... complex thing */  };

C.h（库）

#include "Util.h"
class C{ /* ... complex thing */  };

D.h（用户）

#include "B.h"    //<--- Purpose of #include is to access "B", but not "Util"
class D{ 
    public: static void a(){
        Util::calculate();   //<--- should compile error     
        //When ctrl+space, I should not see "Util" as a choice.
    }
};

我的糟糕解决方案

将Util 的所有成员设为私有，然后声明：-

friend class B;
friend class C;

（编辑：感谢A.S.H“这里不需要前向声明”。）

缺点：-

• 这是一个修改Util以某种方式识别B和C。
  在我看来这没有意义。
• 现在 B 和 C 可以访问 Util 的每个成员，打破任何 private 访问保护。
  有a way to enable friend for only some members，但它不是那么可爱，而且不能用于这种情况。
• D 只是不能使用Util，但仍然可以看到它。
  Util 在D.h 中使用自动完成（例如ctrl+space）仍然是一个选择.

（编辑）注意：一切都是为了方便编码；以防止一些错误或错误使用/更好的自动完成/更好的封装。这与反黑客或防止未经授权访问该功能无关。

（编辑，接受）：

遗憾的是，我只能接受一种解决方案，所以我主观地选择了一种工作量少、灵活性大的解决方案。

对于未来的读者，Preet Kukreti（& texasbruce 发表评论）和 Shmuel H.（&ASH是评论）也提供了很好的解决方案，值得一读。

Answer 1

我认为最好的方法是根本不在公共标头中包含Util.h。

为此，#include "Util.h" 仅在实现 cpp 文件中：

Lib.cpp:

#include "Util.h"

void A::publicFunction() 
{
    Util::calculate();
}

通过这样做，您可以确保更改 Util.h 只会对您的库文件产生影响，而不会对库的用户产生影响。

这种方法的问题是无法在公共标头中使用Util（A.h、B.h）。前向声明可能是这个问题的部分解决方案：

// Forward declare Util:
class Util;

class A {
private:
    // OK;
    Util *mUtil;

    // ill-formed: Util is an incomplete type
    Util mUtil;
}

Answer 2

实现此目的的一种方法是与单个中间类交朋友，该类的唯一目的是提供对底层功能的访问接口。这需要一些样板文件。那么A 和B 是子类，因此可以使用访问接口，但不能直接在Utils 中使用任何东西：

class Util
{
private:
    // private everything.
    static int utilFunc1(int arg) { return arg + 1; }
    static int utilFunc2(int arg) { return arg + 2; }

    friend class UtilAccess;
};

class UtilAccess
{
protected:
    int doUtilFunc1(int arg) { return Util::utilFunc1(arg); }
    int doUtilFunc2(int arg) { return Util::utilFunc2(arg); }
};

class A : private UtilAccess
{
public:
    int doA(int arg) { return doUtilFunc1(arg); }
};

class B : private UtilAccess
{
public:
    int doB(int arg) { return doUtilFunc2(arg); }
};

int main()
{
    A a;
    const int x = a.doA(0); // 1
    B b;
    const int y = b.doB(0); // 2
    return 0;
}

A 或 B 都无法直接访问 Util。客户端代码也不能通过A 或B 实例调用UtilAccess 成员。添加使用当前Util 功能的额外类C 不需要修改Util 或UtilAccess 代码。

这意味着您可以更严格地控​​制Util（特别是如果它是有状态的），因为所有访问都是通过规定的接口，而不是直接/意外访问匿名代码（例如A 和 B)。

这需要样板文件，并且不会自动传播来自 Util 的更改，但它是比直接友谊更安全的模式。

如果您不想子类化，并且很高兴为每个使用类更改UtilAccess，您可以进行以下修改：

class UtilAccess
{
protected:
    static int doUtilFunc1(int arg) { return Util::utilFunc1(arg); }
    static int doUtilFunc2(int arg) { return Util::utilFunc2(arg); }

    friend class A;
    friend class B;
};

class A
{
public:
    int doA(int arg) { return UtilAccess::doUtilFunc1(arg); }
};

class B
{
public:
    int doB(int arg) { return UtilAccess::doUtilFunc2(arg); }
};

还有一些相关的解决方案（用于对类的部分进行更严格的访问控制），一种称为 Attorney-Client，另一种称为 PassKey，两者都在这个答案：clean C++ granular friend equivalent? (Answer: Attorney-Client Idiom)。回想起来，我认为我提出的解决方案是 Attorney-Client 惯用语的变体。

Answer 3

一种可能的解决方案是将Util 推入命名空间，并将typedef 放入B 和C 类中：

namespace util_namespace {

    class Util{
    public:
        static void calculate(); //implementation in Util.cpp
    };
};

class B {

    typedef util_namespace::Util Util;

public:

    void foo()
    {
        Util::calculate(); // Works
    }
};

class C {

    typedef util_namespace::Util Util;

public:

    void foo()
    {
        Util::calculate(); // Works
    }
};

class D {

public:

    void foo()
    {
        Util::calculate(); // This will fail.
    }
};

如果Util 类在util.cpp 中实现，则需要将其包装在namespace util_namespace { ... } 中。就B和C而言，它们的实现可以引用一个名为Util的类，没有人会更聪明。如果不启用typedef，D 将找不到该名称的类。