How to name this key-oriented access-protection pattern?

Question

Apparently this key-oriented access-protection pattern:

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

class Bar {
public:
    void protectedMethod(SomeKey); // only friends of SomeKey have access
};

... doesn't have a known name yet, thus i'd like to find a good one for it so we can refer to it without breaking our tongues. Suggestions?

It should be:

• succinct
• convey the intent of access-protection
• ideally imply that no proxying is required (?)

Gault

Good question. I feel as though it can be re-structured somewhat to allow maximal re-use. Thinking about it... – Greatnephew

@GMan: Now i'm curious, i couldn't see how to improve re-usability. – Gault

Man, it's on the tip of my tongue! Blargh. – Greatnephew

Ah, got it. Typing it up. Simple generalization, almost a bit embarrassed it took me so long. :) (Nothing very drastic, actually...) – Greatnephew

Opened side question on improving re-usability to factor out a side-discussion. – Gault

Answer 1

I like, in decreasing preference:

• passkey friend idiom
• passkey-door friend idiom
• pass-door friend idiom
• key-door friend idiom
• partial-friend idiom
• restricted-friend idiom

_{I moved away from the key-lock/key-keyhole naming scheme to the pass naming scheme, which grew on me.}

Greatnephew

Hm, i had hoped for more voting and to not have to choose between 2 answers... ah well, apparently it doesn't matter to that many people. I'm personally going with passkey now. – Gault

Answer 2

I propose naming this the Badge Idiom, signifying a token presented upon request proving possession of authority. I believe that this is a better metaphor than those revolving around the term Key in many of the other answers here.

'Key' is already fairly overloaded in programming terminology, conflating at least the notions of lookup and of restricted access. Furthermore, real keys usually operate individual locks, not the set of all locks from a manufacturer, and the accepting class in this pattern is a set not of locks but of self-protecting entities being asked to perform actions.

'Badge' conveys the principle that the token grants authority to an entire class of other entities, not just a single object. The term may be too reliant on (US-centric?) police or security imagery, and I did consider terms like Subpoena or Warrant, but they seemed too focused on third party granting of access. Anyway, individuals with a given badge type can compel codified behaviors from the classes of individuals respecting those badges. I see the overall interaction like this:

• A: This party's too loud. Turn down your stereo. (Presents badge)
• B: Oh, OK, officer. (groan)

Trunnel

Hm, i see your point but (for me personally) the association doesn't jump as much into my face as with key/lock et al :) Also keys don't always operate on individual locks: My key for this house here opens my apartment, the main door, the cellar door, ... – Gault

Answer 3

SomeKey looks a bit like a Backstage pass to get into Bar::protectedMethod. So anything in that area should be good: passport idiom, watchword idiom, passkey idiom, VIP idiom..err classy access?

Quiescent

Do you have a single favourite here? I like pass-key the most of these for being short and (at least for me) descriptive. – Gault

Answer 4

There's other ways to do this, in a more general fashion, using inheritance. Here, class cake functions as both the keyhole and the key. Here, any class that inherits (could also be static inheritance) from cake can access the subset of SomeClass defined to be accessible in cake, and of course, you could have multiple different subsets in multiple different classes.

class cake;
class SomeClass {
    friend class cake;
    void foo();
};
class cake {
    void DoFoo(SomeClass& class) { class.foo(); }
};
class lols : cake {
    // Now we can DoFoo().
};

I'd name it lock and key.

Kayser

Although GMan additionally added an extension, the question is still about the naming of the general approach. – Gault

Opened side question so we can make this two separate discussions. – Gault