Re: Ok --- *enough* with the private virtual functions...
Steven E. Harris wrote:
Lourens Veen <lourens@rainbowdesert.net> writes:
That is exactly what he was trying not to think about. The message
you should be sending with this interface is "There's something
called a B, and if you call B::f(), then X will happen to it." No
more, no less.
If there are actually different kinds of B's requiring different
implementations of f() to achieve X, then you might decide to use
derivation and polymorphism in your implementation. But this use of
polymorphism is an implementation issue, and as such it shouldn't
affect the public interface of B.
But all of this is still true of /protected/ virtual functions, which
Java does have. The public method can be marked final, which will then
delegate to an abstract protected method for some of its
implementation. Is the private v. protected trade-off so grave?
Not really. That's exactly what we did in the one important
Java project I worked on.
It does mean that you can't use multiple inheritance (since you
cannot have a non-virtual function in an interface). It's not a
perfect solution, but it can be used in a lot of cases.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
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! ]