Advantages and situations where private data hiding is (not) useful

Recently, I discovered something I should have discovered a long time ago - how to hide a class' private members.

All of you should know this (you are experts ):

Code:

class Implementation; //Forward declaration of the implementation

class Interface {
public:
//yodda yodda, public, private, protected methods

Implementation* ptr;
};

Then I implement the methods in the Implementation class. All makes sence. Pointer sizes depend on the architecture and do not depend on what they point to, that's obvious (how else would void* exist?)

I often want to hide the implementation as far as possible, but I understand that this implementation moves the members into the Heap -- that is obviously a slowdown.

On the other hand, it prevents the user (of the class) from creating additional methods that give him access to the members. But they can always do the same with the pointer can't they? For instance, they can make it point to NULL!

So, when is it useful to do this and when isn't it? Logically, on proprietary/closed-source libraries this is probably used, or are there other methods?

Thanks, Jorl17

A better (and far more common) way to hide the implementation is to do something like:

Code:

// Defines the interface (How the object can be used)
class Interface
{
public:
    virtual ~Interface() {}
    virtual void foo() = 0;
};

// Object implementation.  This can be hidden from library users.
class Implementation : public Interface
{
public:
    void foo() { ... }
};

// Mechanism for creating the object.  All they get is an interface pointer though, so they don't
// know how the interface was implemented.
class SomeFactory
{
public:
    static Interface* CreateObject() { return new Implementation(); }
};

Thanks for that.

That's just like COM, or am I wrong?

It is similar to COM. COM adds the concept of being able to query for an interface, and reference counting all the underlying objects as well.

When you say that implementation is better, why do yu believe it is?

It must have its advantages and disadvantanges. For instance, it seems to me that the first implementation is coded in such a way that a programmer only needs to declare an instance of the class. Whereas this implementation doesn't seem to function that way.

The problem with your example is that it doesn't actually hide anything from the user. If the user has the header file (Implementation.h), then they can bypass the use of the interface class entirely. It also limits the Interface author's ability to swap out the interface implementation with a different class because it will require a change to the Interface class to accomplish this. That can break backwards compatibility with code that already uses the library.

One of the most valuable things that interfaces provide is the ability to be flexible. You lose this advantage as soon as you include a pointer to the implementing class in the interface.

On the other hand, it prevents the user (of the class) from creating additional methods that give him access to the members.

I thought the main advantage is shorter compile times. PImpl gives you more freedom to tinker around with the internal implementation details - adding/removing/changing data members, without requiring recompiling other files depending on the header (can be useful if the class is complicated enough so there may be a need to change data members and such, and included in many other headers).

But then I program alone on my projects and don't sabotage my own classes

For instance, it seems to me that the first implementation is coded in such a way that a programmer only needs to declare an instance of the class. Whereas this implementation doesn't seem to function that way.

They probably have somewhat different usages, I guess (one requires polymorphism, the other not).

Originally Posted by bithub

One of the most valuable things that interfaces provide is the ability to be flexible. You lose this advantage as soon as you include a pointer to the implementing class in the interface.

No you don't. You just forward declare the implementation class.

Code:

class Implementation;

class Interface
{
private:
    Implementation *pImpl;
};

Then, in the .cpp which actually implements the Interface, you define (and implement) the Implementation. This is an extremely common pattern...

Thank you both.

bithub, I understand what you say, except for the part where you say that one can use the implementation directly. No one will ever have implementation.h, simply because that is really hidden and previously compiled either as a library or as an object file. (AFAIK)

I don't, however, understand what changes one must do to the interface when using this technique. If we keep the implementation class backwards compatible, then the interface class will too, I think. What happens is that if we implement a new function, we have to do it everywhere, in the implementation and in the interface.

Interface.h

Code:

class Implementation; //Forward class declaration
class Interface {
Interface(int);
void setValue(int);
int getValue(void) const;
~Interface();

private:

Implementation* ptr;
};

Implementation.h

Code:

class Implementation {

int v;

public:

Implementation (int val) : v(val) { }

void setValue ( int val ) { v = val }

void getValue(void) const { return v; }
};

interface.cpp - Might be hidden from the programmer under a library or an object

Code:

Interface:.Interface ( const int val ) : ptr ( new Implementation(val) ) { }
void Interface::setValue(int val) { ptr->setValue( val ); }
int Interface::getValue() const { return ptr->getValue(); }
Interface::~Interface(void) { delete ptr; }

@anon: I had never thought about that advantage, and it sure makes sense. But a small part of what we gain in compile time, we lose in run-time speed, right?

Originally Posted by Jorl17

I don't, however, understand what changes one must do to the interface when using this technique. If we keep the implementation class backwards compatible, then the interface class will too, I think. What happens is that if we implement a new function, we have to do it everywhere, in the implementation and in the interface.

Not necessarily. The Implementation class does not have to mirror the Interface class. In fact, it could look completely different. That's the whole point of separating the interface from the implementation.

In other words, the Interface does NOT simply forward calls into the Implementation. That completely defeats the point. When the Implementation changes, the code inside the Interface might change, but this is completely invisible to the user of the Interface.

The pimpl idiom does NOT protect you from breaking the interface when you, well, change the interface. Interfaces should be stable. Implementations can vary. If you find yourself needing to change the Interface, then you designed it incorrectly in the first place, and you WILL force a recompile and possibly code changes for the users of that Interface.

In short, don't change interfaces. If you find that an interface is lacking in some way, you should define a NEW interface with a NEW name. This way, users of the old interface can continue to use it, and users who need the new features can use the new interface. Both interfaces might share the same underlying Implementation. Or not. That's the flexibility this pattern grants you.

Yes, my bad, that is correct. the interface may not mirror the implementation and simply use its dark-evil-and-hidden functions to do whatever the dark-force wants it to .

In other words, the Interface does NOT simply forward calls into the Implementation. That completely defeats the point. When the Implementation changes, the code inside the Interface might change, but this is completely invisible to the user of the Interface.

Exactly! Thanks!

In short, don't change interfaces. If you find that an interface is lacking in some way, you should define a NEW interface with a NEW name. This way, users of the old interface can continue to use it, and users who need the new features can use the new interface. Both interfaces might share the same underlying Implementation. Or not. That's the flexibility this pattern grants you.

While I had never thought about it, that's what i've done up until now. For instance, I developed a simple network layer over TCP which used one way of doing things. Then, I developed another version that did the exact same thing and had the exact same procedures, but a completely different (and better) implementation. It was as simple as copy-paste to get it into my apps.