   Structure question
  Suppose I have the following scenario:I have an engine.h file which can be imported by external projects for various engine like things.engine.h depends on several other classes which are included with their .h's.  These classes have publically exposed methods (obviously).  I do not however want these classes exposed to other projects that include engine.h.It is necessary to include them in engine.h as they are required for prototypes in private methods.Thanks,J   
  If you just give your engine class a pointer to these other classes, you will only have to forward declare them.// Engine.h#ifndef ENGINE_H#define ENGINE_H// Forward declarationsclass SoundPlayer;class ResourceManager;class Engine{private:SoundPlayer* sp;ResourceManager* rm;// etc.};#endifThen in engine.cpp, when you actually call the methods, you include the actual files.If your engine is a DLL, you can also just not export those classes and the users won't be able to use them.   ;  Thanks a lot, no, sadly, my engine is a static library, not a .dll...  I don't think I can do the same thing right?Thanks!   ;  As long as the prototypes only reference the items you don't want exposed by reference (as pointers or references), you can forward-declare them, and include the headers only in the .cpp file. See also the "pimpl idiom."Or, you could simply place the "internal" (non-exposed) objects in a different namespace (I typically use one called "internal" or "detail" or some variant thereof) and simply indicate in your documentation somewhere that end-users shouldn't use or rely on anything in that sub-namespace.It's generally really hard to prevent people from doing stupid and/or "malicious" things with your library code (such as accessing private member variables via pointer tricks, et cetera). I tend to prefer the latter solution because its a lot easier for me to work with but still provides a bare minimum of protection against people misuing any classes or functions I've got that are designed for internal use only.   ;  I have a solution for your problem: the bridge pattern. The end user is programming using the interface of class A, but class A itself is a bridge and is only made of very small functions that will, in return, call the real implementation:BRIDGE.Hclass Implementation;class Bridge{  Implementation *implementation; // private implementationpublic:  Bridge(int p1, int p2);  ~Bridge();  void doSomething(int param);};BRIDGE.CPP#include "Implementation.h"Bridge::~Bridge(int p1, int p2){  implementation = new Implementation(p1, p2);}Bridge::~Bridge(){  delete implementation;}void Bridge::doSomething(int param){  implementation->doSomething(param);}The bridge only define the interface that you want to expose, meaning that you can have a better control on the files you'll need to include with your distribution. HTH,   ;  Wow, thanks, both good suggestions...  The Bridge pattern really looks like what i want, although, JPetrie's suggestion is very reasonable too (assuming I am the only person who actually ends up using this engine ^^ ) Thanks guys!