Reputation: 3118
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.
MessageHandler *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 ?
Upvotes: 6
Views: 3717
Reputation: 8053
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.
Upvotes: 0
Reputation: 1312
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
Upvotes: 1
Reputation: 34148
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.
Upvotes: 2
Reputation:
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.
Upvotes: 1
Reputation: 59834
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++.
Upvotes: 6