views:

117

answers:

4

I have two closely related classes which I'll call Widget and Sprocket. Sprocket has a set of methods which I want to be callable from Widget but not from any other class. I also don't want to just declare Widget a friend of Spocket because that would give Widget access to ALL protected and private members. I want to restrict Widget's access to only a specific set of methods.

One solution I came up with is to create a nested class inside Sprocket that contains wrappers for these methods and make Widget a friend of this nested class. For example:

class Sprocket
{
public:
    class WidgetInterface
    {
        friend class Widget;
        WidgetInterface(Sprocket* parent) : mParent(parent) {}

    private:
        void A() { mParent->A(); }
        void B() { mParent->B(); }

        Sprocket* mParent;
    };

private:
    void A() { ... }
    void B() { ... }
};

class Widget
{
public:
    Widget(Sprocket* sprock) : mSprocketIface(sprock) {}

    void doStuff() { mSprocketIface.A(); }  // Widget can call Sprocket::A()

private:
    Sprocket::WidgetInterface mSprocketIface;
};

This results in some code duplication because the method signatures are now declared in two places, but it works. But now suppose I want to add a subclass of Widget called SpecialWidget and I want that class to also have access to the Sprocket methods. I can simply add this new class to the Sprocket friends list or I can add yet another set of protected wrappers in Widget that SpecialWidget (and any other subclass) can access but you can see that this is now becoming a maintenance issue. I don't want to have to update the friends list or the wrappers if I add new classes or change the method signature. If I use the "add another set of wrappers" approach, the method signatures will be duplicated in three places!

Does anyone know of a simpler, cleaner way to do this?

+3  A: 

If you have two tightly coupled classes, then it's really not worth trying to make friend access any more granular than it is. You control the implementation of both, and you should trust yourself enough to not abuse the ability to call some methods that you don't, strictly speaking, need to call.

If you want to make it clear for future code maintainers, add a comment to the friend declaration explaining why it is there (a good idea in general), and what private methods are allowed to be called by the friend class.

Pavel Minaev
You're right in that the simplest solution is to simply make Widget and any subclasses friends of Sprocket. The thing that rubs me the wrong way is that I have to add a "friend" declaration for every subclass, and in the real code there are a lot of them.
Judah Menter
+1  A: 

Sprocket has a set of methods which I want to be callable from Widget but not from any other class.

Why not save yourself some trouble & implement this set of methods in Widget, perhaps adding a Sprocket parameter to these methods?

Pete
+1  A: 

I would have implemented WidgetInterface as a real interface inherited by Sprocket, so A and B are all that Widget know about. Okay, other can use that interface too, but they probably will have a reason for this.

stefaanv
A: 

The secret is all this access control is pointless and illusionary, and there's no way to really limit any access to anything. You are just complicating things and making it difficult to figure out what parts of widget are ok to use and what parts are not. Instead, make the interface for widget and sprocket more obvious, and perhaps have widget own a private sprocket. If people are so clueless that they will violate this there's no help for it, but if you make something abominable and hard to figure out it guarantees even people who know C++ well will be unable to easily make use of it.

Charles Eli Cheese
It IS possible to limit access to specific methods, as the code above demonstrates. However, the complexity makes the code too hard to maintain. In the end I decided to simplify it as you suggest by simply making Widget a friend of Sprocket and adding wrappers to Sprocket's private members there. Now any subclass of Widget can access the Sprocket methods through the wrappers in the parent class. It gives me about 90% of what I want without all the complexity.
Judah Menter
Any class can declare itself a friend of anything or declare it part of any namespace, and can access any memory address that doesn't cause a violation error. You can't stop people from doing stupid things if they have the source at all. If you really want to limit everything you have to have a closed source and provide a limited API in the form of header files that only lets them see the definition of exactly what you want them to use.
Charles Eli Cheese