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