web-dev-qa-db-ja.com

このキー指向のアクセス保護パターンは既知のイディオムですか？

Matthieu M。 アクセス保護のパターンを この回答 で取り上げましたが、これは以前に見たものですが、意識的にパターンを検討したことはありません。

_class SomeKey { 
    friend class Foo;
    SomeKey() {} 
    // possibly make it non-copyable too
};

class Bar {
public:
    void protectedMethod(SomeKey);
};
_

ここでは、キークラスの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をfriendのBarにするよりもきめ細かいアクセス制御が可能になり、より複雑なプロキシパターンが回避されます。

このアプローチにすでに名前があるかどうか、つまり既知のパターンであるかどうかを誰かが知っていますか？

c++design-patternsfriendaccess-control
49
Georg Fritzsche

おかげで あなたの他の質問 このパターンは現在「パスキー」パターンとして知られているようです。

C++ 11では、呼び出す代わりに、さらにクリーンになります

b.protectedMethod(SomeKey());

あなたはただ呼び出すことができます：

b.protectedMethod({});
12
Rick Yorgason

このイディオムは別のイディオムで言及されているようですSO質問 ここ 。これは弁護士-クライアントイディオムと呼ばれ、詳細に説明されています そこに 。

7
Haspemulator

私のような退屈な男が家禽のコードを作るでしょう：

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

これにかなり近い：

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

基本的に、適切に設計されたクラスのオブジェクトへの参照がアクセス制御を提供すると考える場合、実際に意味のあるアクセス制御ポリシーを実装する必要があります。このパターンをコンストラクター以外に適用しても、それほど意味がないようです。

したがって、記事に記載されているように、アクセス制御が意味をなすものとしてこれらのコンストラクターと組み合わせてこのキーを使用すると、C++では一般的にRAIICapまたはRAIIという名前ではなく、RAIIオブジェクトとして実装される恐怖リソースの重要な部分を表すオブジェクト-機能は確かに理にかなっています。

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

または、構成権限などのより一般的な名前で参照することもできます。

この記事の実装は、主に中心的なものです。つまり、主にすべての権限キーを作成する必要があります。キー自体にパブリックコンストラクターを追加することで、拡張して柔軟性を高めることができます。

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

そうすれば、mainはキーの作成をプログラムの他の部分に委任できます。

個人的には、RAIICapの名前はこのパターンの有用な部分に非常に適していると思います。

少し前に、上記のこの単純なテンプレートを標準ライブラリに追加できることを提案しました。

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

残念ながら、計算ルートを構成する1つのメインフィンガープリントが存在する可能性があるという考えには問題があるため、このようなものは明らかに標準ライブラリに配置できません。そうは言っても、少なくともRAIIクラスのコンストラクターで使用する場合、このパターンは非常に役立つようです。

0
user1703394