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.