Restrict access to class

Question

I've got some class - lets call it MyMutableClass, which implements MutableInterface.

class MutableInterface {
  public:
    void setMyPreciousData(int value);
    int getMyPreciousData() const;
    .... //and so on
};

However there is a huge part of code, which should not change the state this class instance, but it need to have a read access.

How to do it in the most polite manner? Should I create an additional ImmutableInterfaces, with getters only and inherits it by MutableInterface? Then I can choose, which one will be passed to another parts of code.

Second option would be to create another class, which object would encapsulate the MutableInterface implementation and provide an access only to a subset of its methods. Is that better?

Is there some well-known patter, which I'm not aware of?

might be a better fit for http://programmers.stackexchange.com/ as this is not strictly C++ — stijn, Mar 11 '16 at 08:02
This is what the const keyword is for. If you present the object as a const reference, you are presenting only the const interface. — Richard Hodges, Mar 11 '16 at 08:11
@Richard Hodges You are definitely right! But I prefer to do not expose the whole interface at all. — Dejwi, Mar 11 '16 at 08:15
Proxy class with restricted interface? Or with some means for access control (exposes interface, but does not give access to it)? — Revolver_Ocelot, Mar 11 '16 at 08:24
@stijn when referring other sites, it is often helpful to point that [cross-posting is frowned upon](http://meta.stackexchange.com/tags/cross-posting/info) — gnat, Mar 11 '16 at 08:25
@Revolver_Ocelot Proxy class should inherits the same interfaces, as object it points to. So I will have to create an "ImmutableInterface"? — Dejwi, Mar 11 '16 at 08:27
You could use the Passkey idiom, explained [here](http://www.spiria.com/en/blog/desktop-software/passkey-idiom-and-better-friendship-c) and [here](http://stackoverflow.com/questions/3220009/is-this-key-oriented-access-protection-pattern-a-known-idiom). — 101010, Mar 11 '16 at 08:33

score 2 · Accepted Answer · answered Mar 11 '16 at 09:28

This won't be what you want to hear, but I think it's important to be said in this case.

Inheritance describes a 'is kind of' interface. The derived thing 'is a kind of' the base thing.

A const thing is not 'a kind of' mutable thing. It's an immutable thing.

A mutable thing is not 'a kind of' immutable thing. It's a thing which happens to be mutable.

Mutability is a property of the thing, not a specialisation.

Therefore, inheritance is the wrong model and this is why in c++, constness is a property, not an interface.

If you really must hide the fact that sometimes a thing is mutable (one wonders why), then as mentioned in the comments, you probably want some kind of proxy view class, such as:

// this is the actual thing
struct the_thing
{
    void change_me();
    int see_me() const;
};

// and this is the proxy

struct read_only_thing_view
{
    int see_me() const { return _reference.see_me(); }

    the_thing& _referent;
};

It is "the second" option, which I mentioned. I also prefer that over inheritance. My only concern is that it is not strictly the "proxy pattern". — Dejwi, Mar 11 '16 at 09:47
@Dejwi I wouldn't get too hung up on slavish devotion to patterns if I were you. They're so 1990s... :) — Richard Hodges, Mar 11 '16 at 10:59

Restrict access to class

1 Answers1