   Naming of Private Implementation Classes
  Assuming I am writing a C++ class library that exposed some abstract classes in public headers whose actual implementations are provided by private classes only known internally in the library. For example:// public headerclass ClientFileServices {  public: virtual void UploadFile(const FileInfo &fileInfo) = 0;};// private headerclass ClientFileServicesImpl : public ClientFileServices {  public: virtual void UploadFile(const FileInfo &fileInfo) {    // [...]  }};Instead of ClientFileServicesImpl, I'd prefer to prefix ClientFileServices with something, but I can't find a short, clear and concise term to indicate that this is a private implementation class. Some ideas I've been playing around with are:- InternalClientFileServices- HiddenClientFileServices- ActualClientFileServices (nope)- ImplementedClientFileServices- PrivateClientFileServices- LocalClientFileServices- RealClientFileServices- ConcreteClientFileServices- TrueClientFileServices (yuk!)How do you name your private implementation classes?Anything from the above? Other recommendations?-Markus-   
  I really don't see the point of exposing an abstract public class if you are only going to have a single implementation. That is just OOP gone bad in my book.Given that we have an abstract ClientFileServices base class, then subclass should be named for the backend they implement: ClientFTPFileServices, ClientHTTPFileServices, ClientNFSFileServices...   ;  The use of a "detail" sub-namespace is common. Of course, that's only a good idea if you're already putting your class library in a namespace. (If you're not, you should be.)namespace mylib{  // public header  class ClientFileServices {    public: virtual void UploadFile(const FileInfo &fileInfo) = 0;  };  namespace detail  {    // private header    class ClientFileServicesImpl : public ClientFileServices { public: virtual void UploadFile(const FileInfo &fileInfo) {   // [...] }    };  }};  Maybe it's just me, but the Impl suffix seems to imply use of the pImpl idiom. Which you aren't using here, so it's confusing.Presumably there are multiple different implementations of the ClientFileServices interface, or at least you are expecting there to be; otherwise you wouldn't be needing this kind of polymorphism. In which case I'd name my concrete implementations according to their specific behaviour, as swiftcoder suggested.   ;Quote:Original post by swiftcoderI really don't see the point of exposing an abstract public class if you are only going to have a single implementation. That is just OOP gone bad in my book.That's a legitimate complaint in C# or other languages with multi-pass compilation. (Unless you're implementing a COM interface.) However, due to the wonderful one pass nature of C++ compilation, if you combine implementation and interface into the same class, you need to recompile clients of the interface if some implementation details change.In this kind of situation, I label the interface with an I prefix and then use the name without the I for the implementation class. Ex: IClientFileServices and ClientFileServices.   ;  We go with the Shim suffix. So ClientFileServicesShim.   ;Quote:Original post by SiCraneQuote:Original post by swiftcoderI really don't see the point of exposing an abstract public class if you are only going to have a single implementation. That is just OOP gone bad in my book.That's a legitimate complaint in C# or other languages with multi-pass compilation. (Unless you're implementing a COM interface.) However, due to the wonderful one pass nature of C++ compilation, if you combine implementation and interface into the same class, you need to recompile clients of the interface if some implementation details change.I would still maintain that this is a use case for delegation, rather than inheritance - particularly the pimpl idiom.   ;  Meh. Six of one, half a dozen of the other.   ;  I also prefix interfaces with I and use the name without the I for implementation. Besides, I've defined an empty macro (as opposed to [your project name]_API macro defined by VS which is used to export symbols from a dll), with which I mark internal implementations. Something like this:#define INTERNALclass INTERNAL ClientFileServices : public IClientFileServices {};Of course you might need to prefix the macro in order to avoid name clashes.   ;Quote:Original post by swiftcoderI really don't see the point of exposing an abstract public class if you are only going to have a single implementation. That is just OOP gone bad in my book.Quote:Original post by sandmanPresumably there are multiple different implementations of the ClientFileServices interface, or at least you are expecting there to be; otherwise you wouldn't be needing this kind of polymorphism. In which case I'd name my concrete implementations according to their specific behaviour, as swiftcoder suggested.There's only going to be one implementation. Let me explain:Assume you had just bought a very badly written 99% C / 1% C++ library consisting of 20 or so static .libs interdependent on each other, each greatly misusing #define macros, importing std:: into the global namespace, #including countless headers and polluting the global namespace with a bazillion cryptically named typedefs and structures.(don't ask... this component is huge, costs a 5 digit licensing fee and happens to be the worldwide standard implementation for some obscure transmission protocol...)What I'm trying to do here is write a simple .dll / .so that hides this monstrosity behind a nice public API.I agree that the implementation class should be named after the specific implementation type, but, as you can probably imagine by now, this would be a chaotic alphanumeric mess of a least 11 characters. Maybe I should just find an internal name for that component. How about 'Joe'?) :)-Markus-