Restricting Class

I want to make a class that can only have its methods called by one other class.

I am thinking right now that I should make everything private, and then make the other class a friend. I am not into the idea of letting the other class have access to my private data members however. If friendship is the only way to achieve this behavior, I think it is worth it however.

I was wondering if anybody else has run into this issue, and what is the best way to approach it.

So if you want your second class to only have "partial" functionality, you can split up the access this way. Perhaps this is better suited to your problem? I dunno. But as long as you don't have any other classes inherit from the first class, I don't see a problem...

It seems to me like the one class containing the other is the best. It's a FortressManager to Fortress relationship, I need all dealings with the Fortresses to go through the FortressManager or else bad things will happen.

I don't think public inheritance is the key for this.
You can use protected inheritance if you want to the class to be derivable, or private inheritance if you wish to disallow deriving.
Public inheritance suggests an is a relationship.

Originally Posted by Adak

io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.

Originally Posted by Salem

You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

I want to make a class that can only have its methods called by one other class.

The private inner class is one way to do that.

Originally Posted by Drac

I am thinking right now that I should make everything private, and then make the other class a friend. I am not into the idea of letting the other class have access to my private data members however.

If class A trusts class B (and only class B) enough to allow calling of non-public member functions (that's what friendship means between C++ classes) why can't class B be trusted with other non-public attributes?

As a rough rule, declaring friendship means that the programmer knows exactly what the friend class will do with its access.

Originally Posted by Drac

If friendship is the only way to achieve this behavior, I think it is worth it however.

It's not the only way, but it is often the most logical way. There are various techniques, but you have to be specific in your goals (you have been specific in the form of solution you seek, which is not the same as being specific in your goals).

I suggest you need to justify why you want to allow partial access.

But to give you a hint, depending on what your goal is, alternatives include friendship, facade pattern, containment, a private inner class, and the pimple idiom.

It's part of a game, I posted it in these forums because it seemed more like a broader issue. Fortress has methods such as addBuilding, which would make it seem like you could call this to add a building without any problems. Sadly if somebody did this they would be bypassing the collision detection that is done in FortressManager. I wrote this in the documentation, but I want a way to ensure that neither I or anyone else would access Fortress directly from anywhere except FortessManager.

After this discussion the private inner class seem to me like the best and most explicit way to accomplish this.

The use of friend here, in my opinion, is a correct use. It is actually enhancing encapsulation and thus extending the protection. I have used this paradigm before and it works well. However it does not lend itself well to interfaces since friendship cannot be inherited. So you can't make the class a friend of the base and also of all it's derived. It is only a friend of the base and if the base is abstract then you have gained nothing. If you make the class a friend of the derived, it is only a friend of the derived you specified and not a friend of every derived that is derived from base.

I have found the easiest way to enforce the idea that only certain objects can call functions in other objects is through friendship. Most people absolutely detest the use of friend but it does have it's legitimate uses and trying every other construct just to keep yourself from using friend may result in a more complex system that is overdesigned for the task.

You can also affect 'visibility' of functions through interfaces but it can get complex fairly quickly. You would return a pointer to an interface that did not support the functionality you are wanting to hide but did support all of the functionality that every object can access. To the one object that can indeed use the 'hidden or forbidden' functionality you would return the interface that supported those functions. In this way you would limit which objects could access specific functions in another object. I believe this would fall under the aforementioned 'facade' pattern.

Inherited friendship would be a very nice addition to the language since you could then say that since class A is a friend of Base and Derived is derived from Base then A is also a friend of Derived. As it stand now A is only a friend of either Base or Derived but never both unless friend is both declared in Base and Derived...in which case the declaration in Base is a moot point.