Re: Private vs. protected functions for refactoring
Niklas Matthies wrote:
On 2006-09-12 23:27, Lourens Veen wrote:
Niklas Matthies wrote:
A client like
void f(ClassWithProtectedMembers & foo)
{
foo.protectedMemberFunction(); // won't compile
}
cannot access the protected members *of the instance passed
to it* other than looking at the bytes. The members of this
instance are just as protected from that client as with
private. It's certainly not the same as if they were
public.
But it can do
#include "classwithprotectedmembers.hpp"
class MyClass : public ClassWithProtectedMembers {
MyClass() {
protectedMemberFunction();
}
};
and you still need to document protectedMemberFunction() in
the same way that you would a public member function. A
member function that is declared protected is not declared
public, but it may still be seen and used by outside code
via inheritance, and in that respect it's "part of the
public interface".
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. I don't see how making them
protected changes this.
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!). The important thing, in the
context of this thread, is that making something protected, on
the grounds that someone might want to use it, breaks
encapsulation in the same way that making them public does: it
reveals details of the implementation to external parties. I
probably overstated the issue when saying that "you might as
well make it public", but I was thinking in the context of the
original posting---whether you make the otherwise private
function protected or public, it becomes part of your
contractual interface, and ceases to be an implementation
detail.
(And even then... on occasion, I've created protected
"convenience" functions, functions which do something that I
think a lot of derived classes might need. Which is about what
the orginal poster was asking about. But it's always been a
special case, something more or less exceptional, and not a
general rule. And of course, it also meant, in each case, that
I promessed to always make that function available, in all
future versions.)
--
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! ]