Re: Private vs. protected functions for refactoring
Roy Smith wrote:
Any thoughts on how to approach the private-vs-protected issue?
If you are using a language where objects are the only data structures
then this dichotomy stands, but that isn't the case for C++.
I've not seen anybody raise a third option and that is to put the
common code into an anonymous namespace in the implementation file.
This has the added advantage of not requiring a header file change so
is even better for refactoring - much less recompilation.
If the common code can get away with using only the public interface
then this seems the best way to do it. If it needs privilages then it
may be harder, but this depends on what you are doing. For example, you
could pass references to any protected/private members that need to be
changed - breaking encapsulation in this way is of much less concern in
this situation as there will be no access to the function at all
outside the class implementation.
This is what I do most of the time that I want to eliminate common code
within a class. Why clutter up the header at all with private members
when there is no need?
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]