Re: When to hide implementation details
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