   hidden inter-object communication
  I have two objects of different classes A and B that should pass data between them. However I do not want to extend the public interface of both classes as those additional methods should not be accessible by the user of the classes. I thought about two solutions:1) Introduce a special naming scheme to denote those methods that are not supposed to be called by the user. (the OGRE engine does something like that, prefixing those methods with an underscore)2) Use a friend relationship. I would prefer using friend, although I think its suboptimal. How can I keep the public interfaces of both classes clean while enabling communication between them?   
  Have a higher level, or otherwise third-party, object handle the communication.Please provide more contextual information.   ;  I'm designing a client-server application: Normally client and server communicate via network. However if the client and server run on the same machine (as different threads in the same process) the walk through the network stack should be removed.For example, if the client sends a packet to the server (in the configuration that both run on the same machine), internally the client would call server->addPacket(). Making the addPacket method publicly available would seem rather awkward to the user of the library.   ;  Abstract the client and the server network layer so that instead of sending and receiving data directly from the network they send and receive from a proxy class. Implement the proxy classes with both a networking implementation and an in-memory queue implementation. Instantiate the correct proxies for which communication mode is being used.   ;Quote:Original post by SiCraneAbstract the client and the server network layer so that instead of sending and receiving data directly from the network they send and receive from a proxy class. Implement the proxy classes with both a networking implementation and an in-memory queue implementation. Instantiate the correct proxies for which communication mode is being used.So you would have two proxy classes? (one with networking, the other with an in-memory implementation)This might pose a problem for the server as it has to be able to communicate via network and via memory at the same time. Therefore you would have to instantiate both proxies and everytime you do something with a client figure out whether the client is remote or local in order to choose the proper proxy object.   ;  It's really not that bad. You have a base class interface that the server uses to communicate with the client and when the client connects instantiate the correct object for the client type. Then the server just uses the interface with virtual functions (or whatever polymorphism mechanism your language supports) and doesn't need to do any checking other than when the client first connects. And since the client connection is going to be very different depending on if its a network or a local client then there isn't any real difficulty in creating the proper connection object.   ;Quote:Original post by SlimTimmyI have two objects of different classes A and B that should pass data between them. However I do not want to extend the public interface of both classes as those additional methods should not be accessible by the user of the classes.A and B are "the user" of each other; if they exchange dangerous or too intimate method calls, maybe they can be redesigned with a more abstract interface that doesn't need them.For example, to clarify SiCrane's suggestion, the addPacket method on the game server you mention might be inappropriately low level because it deals with irrelevant networking details like protocol packet headers and IP addresses, which is inappropriate when in-memory transport enters the picture.Better server and client interfaces would deal with naked application messages and with objects representing sender and destination identities (encapsulating the different communication mechanisms). 