Re: Private vs. protected functions for refactoring
Niklas Matthies wrote:
On 2006-09-14 12:08, kanze wrote:
Niklas Matthies wrote:
It's part of the "public" interface of the class, but not
necessarily of the instance. James Kanze concluded: "In
practice, I don't think I've ever made anything in a
globally accessable class protected; might as well make it
public, and be done with it." I don't agree that making it
public is "as well" - it exposes the member to clients that
get instances passed to them where you (or whoever creates
the instances) might not want that member to be exposed to
those clients for the specific instances you pass to them,
all the while permitting other creators of instances of the
class to expose the member in their instances if they wish
to do so.
You seem to miss the point: anyone who wants to call the
functions can, with no trickery.
How so (for an existing instance)?
I don't quite see the point of the existing instance. The point
is that I can derive from any class, and call them.
Incidentally, private virtual member functions are also
part of the "public" interface of a class - might as well
make them public... (not!)
There's a big difference: even a derived class cannot call
them (unless it implements them).
Anyway, I don't think it is a big point. I think you agree
that protected functions are part of the "contractual"
interface (as are private virtual functions!).
IME classes have two contractual interfaces, the client
interface and the interface towards derived classes (the
latter can generally be considered to include the former).
"Protected" translates into "private" for the client interface
and "public" for the derivation interface.
Except that unless you can control who derives, you've
effectively allowed everyone access to the protected interface.
That doesn't mean that you can't propose two (or more)
contracts. It's quite common, as you say, to propose a
different contract for derived classes. It's also common (at
least in my code) to provide a separate, read only contract for
certain users. In large projects, it's frequent to specify
different contracts at the sub-system interface than within the
sub-system. (Not all of these distinctions are directly
supported by the language, but it's usually possible to create
them without much effort.)
--
James Kanze GABI Software
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]