没有功能可以控制C++中类的可见性/可访问性。
有什么办法可以伪造它吗？
是否有任何宏/模板/魔术C++可以模拟最接近的行为？
这是情况
Util.h(library)
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"这里不需要前瞻声明"。
缺点：-
- 以某种方式识别
B和C是一种修改Util。
在我看来，这没有意义。 - 现在B和C可以访问
Util的每个成员，打破任何private访问卫士。
有一种方法可以只为某些成员启用朋友，但它不是那么可爱，在这种情况下无法使用。 D只是不能使用Util，但仍然可以看到它。
在D.h中使用自动完成(例如ctrl+空格)时，Util仍然是一种选择。
(编辑)注意：这完全是为了方便编码;防止一些错误或不良使用/更好的自动完成/更好的封装。 这与反黑客攻击无关，或防止未经授权访问该功能。
(编辑，接受)：
可悲的是，我只能接受一种解决方案，所以我主观地选择了需要较少工作并提供很大灵活性的解决方案。
对于未来的读者，Preet Kukreti(评论中的德克萨斯布鲁斯)和ShmuelH.(评论中的A.S.H)也提供了值得一读的良好解决方案。
我认为最好的方法是根本不在公共标头中包含Util.h。
为此，仅在实现cpp文件中#include "Util.h"：
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;
}
一种可能的解决方案是将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将无法找到该名称的类。
实现此目的的一种方法是与单个中间类交朋友，该中介类的唯一目的是提供对基础功能的访问接口。这需要一些样板。然后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); }
};
还有一些相关的解决方案(用于对类的各个部分进行更严格的访问控制)，一个称为律师-客户，另一个称为PassKey，这两个解决方案都在此答案中讨论：干净C++粒度的朋友等价物？(答案：律师-客户成语) .回想起来，我认为我提出的解决方案是律师-客户习语的变体。