When to hide implementation details

[Ralph]

Hi,

I was reading effictive C++ and some other books again and they all tell
you about hiding implementation details (proxy/pimpl/inheritance) but
they never really explain when to use it.

I am starting on a new project which is part library so I think it would
be good to hide the implementation for the public classes in the library
but this seems a lot of overhead to me (both when developing and runtime
overhead).

For example, it needs to interface with C and I created a class
MemoryBuffer which basically just allocates memory and allows some
operations on the memory buffer. This class is in this library and is
used by several client applications. So, should I hide the implementation
for this class? I think I would but somehow this seems like lots of
unneeded overhead.

Another example, I have exception classes which stores a message and some
other information. Should I hide this information?

Anyway, my concern is that if I just hide all implementation details I
might overdo the whole implementation hiding idea and make the code less
clear and maintainable. Are there any rules on when to hide
implementation and when not ?
The only rule I could find is basically 'hide everything and when the
profiler says it is slow, unhide it'. Is this a good approach ?

I hope you understand what I am trying to say and have some good advice.
Thanks,

Ralph.

 

[Jim Cobban]

I was reading effictive C++ and some other books again and they all tell
you about hiding implementation details (proxy/pimpl/inheritance) but
they never really explain when to use it.
....

Anyway, my concern is that if I just hide all implementation details I
might overdo the whole implementation hiding idea and make the code less
clear and maintainable. Are there any rules on when to hide
implementation and when not ?
The only rule I could find is basically 'hide everything and when the
profiler says it is slow, unhide it'. Is this a good approach ?

Hiding the implementation does result in a performance hit because all
actions must be redirected to the underlying implementation, and you
cannot take advantage of inline.

The most common reason for hiding the implementation is to avoid the
necessity to recompile all of the programs that reference a library. So
commercial libraries usually hide their implementation so their
customers can install new versions of their product without having to
recompile all of their applications. For example consider the havoc
that would arise if every time Microsoft issued a fix to their libraries
everyone had to recompile all of their applications! However if your
library has only a small well-known set of clients then requiring a
global recompile may not be a big deal.

 

[Stefan Ram]

The only rule I could find is basically 'hide everything and when the
profiler says it is slow, unhide it'. Is this a good approach ?

You hide the implementation, so that you can change it later
without changing the interface, which might break clients.

For example, this account class was found in the web:

class Account
{ public:
Account( int myMoney ): moneyAmount( myMoney ){};
int getMoney() const{ return moneyAmount; }
private:
int moneyAmount; };

It exposes the type »int« of its private field »moneyAmount«
in the interface. So, one can not change this field's type to
»long« later without breaking the interface (or not taking
full advantage of this change).

Exercise: Devise an account class that does not expose the
type used internally to store the amount in its interface, so
that this type can be changed later. (For example, it might
be changed from »double« to a type using a decimal value
representation with arbitrary precision, while the interface
is not being changed.)

 

[Ralph]

What would be the reason you don't want people or tools to see
something?

Ah, yes, that was what I forgot to mention:
My main reason for hiding is to prevent recompiling everything when
something changes in the implementation and have a cleaner interface for
other users without all the distracting private stuff.

If you can't find a good reason to hide that, and all you can see is the
overhead, then why hide? See the reasons I enumerated above.

I was just wondering because all the books says hiding implementations is
a good idea but they almost never tell you when you should use it.

Again, it's _competely_ up to you. We can't "should" you, we can only
tell you where others hide some implementation and why (if they actually
told us or we guessed).

Ok, then I should have asked 'when do you hide implementations?'
So, when do you hide implementations?
Are there some general guidelines?

No. If the profiler tells you to unhide a state secret, for which you
can go to jail for life, would you do that?

Well, I think they mean just hide the implementation of all classes but
in the final product you can unhide performance bottlenecks.


Thanks,

Ralph

 

[Matthias Buelow]

I was just wondering because all the books says hiding implementations is
a good idea but they almost never tell you when you should use it.

Probably they all copy it from earlier books .
The main reason is that a programmer using a module is less inclined to
rely on implementation details (a bad thing to do) if the implementation
is somehow hidden and only an interface is visible. I doubt that
actually forbidding the programmer access to implementation details is a
good idea, though. It isn't really possible with open-source anyways and
if the programming language doesn't allow it, programmers will find some
workaround, which will not be pretty either.

 

[Ralph]

I was reading effictive C++ and some other books again and they all tell
you about hiding implementation details (proxy/pimpl/inheritance) but
they never really explain when to use it.

After reading all the comments and thinking about it I think I just don't
hide implementation details unless recompiling is going to take a long
time after a really small change. Since my project is not that huge, it
should be ok without hiding implementations.

Thanks again.

Ralph.