Abstract class - hiding implementation in C++ practice

Recently I've been writing code similar to this:

messagehandler.h:

#include "message.h"
class MessageHandler {
public:
   virtual ~MessageHandler() {}
   virtual void HandleMessage(Message *msg) = 0:
};

persistmessagehandler.h:

MessageHandler *CreatePersistMessageHandler();

persistmessagehandler.cpp:

#include "messagehandler.h"
#include "persist.h"

class PersistMessageHandler : public MessageHandler {
private:
   PersistHandle ph;
   size_t count;
   InternalCheck();
public:
   PersistMessageHandler(int someParam);
   virtual ~PersistMessageHandler ();
   virtual void HandleMessage(Message *msg):
};
PersistMessageHandler::PersistMessageHandler(int someParam)
{
  ph.Initialize();
}
... rest of implementation.

开发者_如何学JAVAMessageHandler *CreatePersistMessageHandler(int someParam)
{
  return new PersistMessageHandler(someParam);
}

The reasoning here is to hide the PersistMessageHandler. Clients don't need to include a header for the PersistMessageHandler class, with all the includes and types the implementation might need, and to more cleanly seperate the interface and implementation. . It'll always be dynamically allocated anyway,

All PersistMessageHandler users will just call CreatePersistMessageHandler(..); directly or indirectly get one from a factory.

But. I've not seen this approach used much elsewhere. Is the above good practice ? Are there other/better alternatives for simple cases ?

You always have to hide as much as possible. Your way (putting implementation classes into .cpp) is a common way to do this in c++.

This is a good way to hide implementation details from your clients. If you are working in Windows, you might also consider using an __interface instead of an abstract base class.

An Interface is an MSVC compiler extension that looks like an abstract base class, but has different rules for creation and destruction than a normal c++ class. It's the standard way of working in Windows, so there are system supported facilities for working with out-of-process objects and for using them in .NET code.

Sure - it looks like a form of the factory pattern. Users of the factory aren't interested in its internal details, they only care about the things it creates.

The process of hiding the implementation details is called Encapsulation. The process of minimizing build dependencies for your users is called Insulation. There is a great (but aging) book by John Lakos devoted to both topics:

http://www.amazon.com/Large-Scale-Software-Design-John-Lakos/dp/0201633620

Minimizing dependency on implementation details is indeed great, and hiding things beyond abstract base class (ABC, aka interface) is a good and idiomatic solution.

The downside of using ABC is that you lose value semantics of your class which could be or couldn't be acceptable/desirable.

One technique that also hide implementation details without this drawback is Pimpl. Guess you should be aware.

I'll prefer ABC in most cases.