这种以密钥为导向的访问保护模式是一种已知的习惯用法吗?

Matthieu M.在这个答案中提出了一个获取保护的模式,但是从未有意识地考虑过一个模式:

class SomeKey { friend class Foo; SomeKey() {} // possibly make it non-copyable too }; class Bar { public: void protectedMethod(SomeKey); }; 

这里只有key类的一个friend可以访问protectedMethod()

 class Foo { void do_stuff(Bar& b) { b.protectedMethod(SomeKey()); // fine, Foo is friend of SomeKey } }; class Baz { void do_stuff(Bar& b) { b.protectedMethod(SomeKey()); // error, SomeKey::SomeKey() is private } }; 

它比Foo成为Barfriend更好的访问控制,避免了更复杂的代理模式。

有谁知道这种方法是否已经有一个名字,即是一个已知的模式?

感谢您的其他问题 ,看起来这种模式现在被称为“密钥”模式。

在C ++ 11中,它变得更干净,因为不是调用

 b.protectedMethod(SomeKey()); 

你可以打电话给:

 b.protectedMethod({}); 

看来这个成语像另外一个在这里提到的问题。 它被称为律师客户成语,并在那里更详细地描述。

一些像我这样无聊的人会做出f code的代码:

 int FraudKey=0; b.protectedMethod(reinterpret_cast<SomeKey&>(FraudKey)); 

它非常接近这个:

http://minorfs.wordpress.com/2013/01/18/raiicap-pattern-injected-singleton-alternative-for-c/

基本上,如果考虑引用devise良好的类的对象来提供访问控制,则需要实现任何实际上有意义的访问控制策略,但将此模式应用于构造函数以外的其他任何东西似乎都没有多大意义。

因此,正如文章所述,如果您将这个密钥与这些构造函数一起用于访问控制可能是有意义的,那么表示恐慌资源的重要部分的对象,在C ++中通常将被实现为RAII对象,而不是名称RAIICap或RAII能力确实有道理。

http://www.eros-os.org/essays/capintro.html

或者,你可以用一个更通用的名字来引用它,比如构造权限。

文章的实施主要集中在一点,即主要需要创build所有的权限密钥。 您可以扩展它,并通过为密钥本身添加一个额外的公共构造函数使其更加灵活:

 template <typename T> class construct_authority { public: construct_authority(construct_authority<void> const&) friend int main(int,char **); private: construct_authority(){} }; 

这样主要可以将关键创作委托给程序的其他部分。

就我个人而言,我认为RAI​​ICap的名字对于这种模式的有用部分是非常合适的。

前一段时间,我曾经build议这个简单的模板可以添加到标准库中。

https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/p_v-aYIvO1E

不幸的是,存在一个问题,即可能有一个主要指纹构成一个计算根,所以像这样的东西显然不能在标准库中占有一席之地。 说了这些,至less对于RAII类的构造函数来说,这个模式似乎是非常有用的。