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.

[Victor Bazarov]

Ralph wrote:

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.

Early reaction: you hide something you don't want others to see.

What would be the reason you don't want people or tools to see
something? It could be (a) proprietary technology you're proud
of but want to keep secret, (b) bad code that you're ashamed of,
(c) something that could make people/tools waste too much time
looking at or exploring. There are probably other reasons that
at this time escape from me.

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.

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.

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

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).

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 ?

No, there are no rules. There are general guidelines, maybe.

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 ?

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

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

Performance [of the final code] is rarely a concern when hiding
implementation details is discussed. Performance of the compiler,
OTOH, is. One of the reasons for PIMPL pattern is to _reduce_
dependencies between modules, so when you change one, you don't
have to recompile the other.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[Jim Cobban]

Ralph wrote:

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.

[Ralph]

On Thu, 24 Apr 2008 10:12:55 -0400, Victor Bazarov wrote:

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?

>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 ?

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

[Victor Bazarov]

Ralph wrote:

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

Generally, if your implementation is dynamic, you have no other
choice but to use the pimpl idiom. The pointer is to the base
(usually abstract) class that implements some behaviour and the
actual implementation is obtained from an external module loaded
by the system based on some kind of configuration setting. This
is the strongest reason to "hide" the implementation. Making
the object lightweight if it's stored/copied much more often than
its implementation counterpart is another reason. Whether you
actually _hide_ the implementation or simply _separate_ it from
the "interface", is up to you, but I'd consider it "hiding".

>>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 ?

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.

The point is, you have to weigh the relative importance of the
reasons you used to hide the implementation versus the reasons
telling you to expose it. If the performance is important, and
more than the ability to substitute implementations without
forcing your class users to recompile, put everything in one
class and be done with it, if you found that separating the
implementations causes performance problems. But I thought that
it went without saying...

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[Matthias Buelow]

Ralph wrote:

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]

On Thu, 24 Apr 2008 13:33:39 +0000, Ralph wrote:

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.