"All public methods should be virtual" - yes or no / pros & cons

[Frank Oquendo]

In C++. I failed to notice that this was cross-posted to the C#
group as well. More's the pitty for C# - it's a valuable idiom that
they've ruled out (Java made the same mistake).

I fail to see what's so terrible about it. Marking a member as protected
makes it accessible to derived classes thus giving a type's author the
ability to retain complete control over a private member.

I see the ability override private members as a problem, not a feature.

--
There are 10 kinds of people. Those who understand binary and those who
don't.

http://code.acadx.com
(Pull the pin to reply)

 

[Frank Oquendo]

In this case it's important to be clear about what it is that is
private. Certainly private should mean that no other class may access
the member. Whether it should mean that you can't override it if it's
declared virtual is another matter altogether. There are many
situations where private virtuals as implemented in C++ are
appropriate. I too would like to know why they are prohibited in C#.

Because they're unnecessary thanks to the protected keyword. Why support two
ways to override a member when one access modifier has semantics the other
does not?

Considering nothing is virtual by default in C#, it makes perfect sense to
use protected virtual instead of private virtual.

--
There are 10 kinds of people. Those who understand binary and those who
don't.

http://code.acadx.com
(Pull the pin to reply)

 

[n!]

Because they're unnecessary thanks to the protected keyword. Why support
two

ways to override a member when one access modifier has semantics the other
does not?

Considering nothing is virtual by default in C#, it makes perfect sense to
use protected virtual instead of private virtual.

The point about "private virtual" is that it allows child classes to
override the method but not call it, if the same method is defined
'protected virtual' then a derived class *can* call it. Whilst it may seem
esoteric, there are times when it's useful. Though TBH I've never needed
private virtual in C# so far.

n!

 

[Carl Daniel [VC++ MVP]]

I fail to see what's so terrible about it. Marking a member as
protected makes it accessible to derived classes thus giving a type's
author the ability to retain complete control over a private member.

The problem is that it makes it impossible to use design by contract and
guarantee that the contract is not violated. If you don't want to use
design by contract, then you'll never realize the loss of that ability.

The reason it damages design by contract is that it allows derived classes
to break the contract, since they can invoke their own virtual functions
without going through the public (contract-enforcing) interface.

I see the ability override private members as a problem, not a
feature.

The fact that a method is virtual means that a derived class can replace it.
The fact that a method is private means that only the declaring class can
access it. The two are completely orthogonal concepts - why tie them
together artificially?

-cd

 

[Carl Daniel [VC++ MVP]]

protected means they are visible in inherited classes, wtf good is a
private declared virtual when u cant override them?

protected means they're accessible in derived classes. It has no bearing
(in C++) as to whether a declaration in a deriving class overrides a
(virtual function) declaration in a base class.

-cd

 

[Guest]

protected means they are visible in inherited classes, wtf good is a private
declared virtual when u cant override them?

 

[Martin Maat]

Ken,

I'm on a team building some class libraries to be used by many other
projects.

Some members of our team insist that "All public methods should be virtual"
just in case "anything needs to be changed". This is very much against my
instincts. Can anyone offer some solid design guidelines for me?

They are missing the point of object orientation. The first and foremost
benefit is not "ultimate" flexibility", neither is is re-use. The main
benefits are control of complexity; 1:1 mapping of the real world to a model
and comprehensiveness.

First, virtual methods do not come free, they perform worse than non-virtual
methods. Now this may be an issue and it may not, depending on the kind of
application and the way the methods are used.

Another thing. If something is declared virtual, that is a statement on the
part of the designer. It implies some generic behavior that may need to be
altered somehow for any derived.class in order to obtain the desired
behavior. It helps the developer understand the problem domain. Declaring
everything virtual is bad because the developer will wonder how he should
deal with the method in e derived class. Must he override it? Must he call
the inherited implementation? Before or after his own actions? Can he leave
it like it is? If I were that developer and I had been thinking this over,
trying to understand the purpose of a particular virtual method not
understanding how to deal with it and I finally went go to the designer of
the base class and I would ask why and he would say "For no particular
reason, I just couldn't be bothered thinking too hard about the consequences
of sealing it so I left it all open for you, providing ultimate flexibility,
so you can do the thinking I could not be bothered with, aren't you happy?"
Then I would not be happy.

Imagine every public method of a fairly complex class being virtual. Most of
them will implement fixed behavior that is not supposed to be overridden. It
would only invite developers to screw things up and they would not
understand what is expected of them.

Finally, if at some point "something needs to be changed" and polymorphism
would be the answer, then that would be the right moment to open the base
classes source and change the declaration for the particular method to
protected (not public, heaven forbid).


I read the discussion on private virtual methods too. While some languages
may technically allow them they don't make sense. In Delphi for instance you
can declare both the base class's virtual methods and the overrided derived
class's method private but that only compiles as long as both the base class
and the derived class are in the same source file. Once the derived class in
in a different source file, all the base class's private methods are
invisible and the project won't compile. Needless to say that little
projects have all classes declared in the same source file. Since it only
works if you put everything together or make everything friend with
everything else it is absolutely pointless because you can in those
situations access anything in your base class from anywhere, it is as good
as putting everything in the same class right away and not derive at all.

So the boys are wrong, you are right. Rub it in.

Martin.

 

[Guest]

I wont be buying your product then as its gona perform like the shit with
everything virtual for no damn good reason.

 

[Frank Oquendo]

The reason it damages design by contract is that it allows derived
classes to break the contract, since they can invoke their own
virtual functions without going through the public
(contract-enforcing) interface.

I don't get it. Can you show me an example?

The fact that a method is virtual means that a derived class can
replace it. The fact that a method is private means that only the
declaring class can access it. The two are completely orthogonal
concepts - why tie them together artificially?

They're not tied together at all. The accessibility of a member and the
ability to override that member are controlled through two separate
mechanisms.

--
There are 10 kinds of people. Those who understand binary and those who
don't.

http://code.acadx.com
(Pull the pin to reply)

 

[Martin Maat [EBL]]

The point about "private virtual" is that it allows child classes to

override the method but not call it, if the same method is defined
'protected virtual' then a derived class *can* call it.

Okay, that makes sense. Technically that is.

there are times when it's useful.

Name one .

I am serious, I have been giving this some thought just now but I cannot
come up with a sensible reason to do this. It makes me think of Tommy Cooper
("Pick a card, any card... No, not that one!"). Here's a method, you can use
it.. No you can't!.

Basically, it is an abstract interface with a default implementation (don't
these words make your brain turn?). The "benefit" would be that you do not
force the user to implement it as with abstract methods and you keep the
possibility of creating an instance of the base class.

I don't like it. Since the method's implementation has no generic purpose it
should not be visible. It should be totally encapsulated. The need for an
abstract interface with the same signature stands apart from the base
class's private implementation. The abstract method should therefore be
declared separately.

Whenever private virtual seems to apply, it seems to me it is only abusing
coincidentially matching method signatures. You need some implementation in
your base class on one hand and you need some abstract method to put derived
classes on the right track on the other hand, the signatures match and you
go like "Hey... I can make that one method.". Yes, you can, but it doesn't
make sense to do so, it is only confusing.

Martin.

 

[Carl Daniel [VC++ MVP]]

I don't get it. Can you show me an example?

Imagine that you have a class (C++ syntax):

class C
{
public:
virtual ~C() {}
void process()
{
part_a();
part_b();
part_c();
}

private:
void part_a() {}
virtual void part_b() {}
void part_c() {}
};

This class is clearly designed to be used polymorphically: the virtual
destructor and virtual part_b indicate this.

How is a class used polymorphically? Through a pointer (or reference) to a
base class. Using a pointer to the base class (C), only the process()
method is available - that's the public interface of C.

A derived class can override part_b, but it cannot invoke any of the parts
of process (part_a, part_b, part_c) independently.

Now, imagine that part_a() validates that the object is in a coherent state
and logs the start of process(), while part_c re-validates that the object
is in a coherent state, logs the end of process() and frees resources
acquired in part_a. (Clearly there would be exception safety issues to deal
with, but that's independent of this example).

By having part_b private, a derived class can replace the implementation of
part_b, but cannot ever call it without going through process() - going
through process enforces the invariants of the class:

- The object is in a valid state before the operation
- The start of all operations is logged
- The end of all operations is logged
- The object is in a valid state after the operation

This general pattern is called "Design By Contract" (DBC). C++ lets you
implement and enforce DBC directly. C# and Java prohibit you from builing
an enforceable DBC. Of course, you can create the same mechanisms in C#,
but you can't ensure that they'll be used. If part_b where public or
protected (as required in C#/Java), any other method of a class overriding
part_b could invoke part_b directly thus skipping the invariant checks.

They're not tied together at all. The accessibility of a member and
the ability to override that member are controlled through two
separate mechanisms.

If you can't override a private member then they're tied together.

-cd

 

[Jon Skeet [C# MVP]]

Carl Daniel [VC++ MVP]

The fact that a method is virtual means that a derived class can replace it.
The fact that a method is private means that only the declaring class can
access it. The two are completely orthogonal concepts - why tie them
together artificially?

That may be what private means in C++, but in C# it's much simpler:
private means that the member is in no way visible to any other types
(outside reflection, of course). This is a much simpler view of the
world, IMO, and easier to understand.

 

[Carl Daniel [VC++ MVP]]

Okay, that makes sense. Technically that is.


Name one .

See the example I just posted elsewhere in this thread. This is actually a
very useful design pattern - not at all esoteric once you understand it.

-cd

 

[Carl Daniel [VC++ MVP]]

Carl Daniel [VC++ MVP]

The fact that a method is virtual means that a derived class can
replace it. The fact that a method is private means that only the
declaring class can access it. The two are completely orthogonal
concepts - why tie them together artificially?

That may be what private means in C++, but in C# it's much simpler:
private means that the member is in no way visible to any other types
(outside reflection, of course). This is a much simpler view of the
world, IMO, and easier to understand.

It's clearly simpler, and it may well be easier to understand (personally I
din't think so, but then I'm from a C++ background).

The significance of this thread though is to amplify the point that this
simplification comes with a cost: certain very valuable design idioms are
simply not possible in C# (or Java) because of the restriction on overriding
a private method.

-cd

 

[Martin Maat [EBL]]

Okay, that makes sense. Technically that is.

See the example I just posted elsewhere in this thread. This is actually a
very useful design pattern - not at all esoteric once you understand it.

You claim that C++ has this wonderful ability that C# and other OO-languages
lack. Having read your clear example I say DBC can be implemented much, much
nicer and cleaner using events because that is precisely what it is. The
base class provides a way to plug-in client-provided logic. Now C++ does not
support that natively so some horrible hack like a private virtual method
was used to achieve this. I am willing to call the solution "creative" and I
respect the work of the pioneers that started the programming industry as we
know it. Fortunately, we don't have to do it that way anymore these days
.

Martin.

 

[Brandon J. Van Every]

The point about "private virtual" is that it allows child classes to
override the method but not call it, if the same method is defined
'protected virtual' then a derived class *can* call it. Whilst it may
seem esoteric, there are times when it's useful. Though TBH I've
never needed private virtual in C# so far.

It *is* esoteric, and I would wager that the C# language designers chose
simplicity in the interest of industrial robustness. "Industrial
robustness" in the real world means simplifying things so that the vast
majority of average programmers understand what's going on. C++ is a very
tweaky language with lotsa weird cases. C#, philosophically, is clearly an
attempt to clean up C++'s mess.

This observation may be lost on hardcore C++ programmers, and that is
precisely the point. In the long haul, C# will replace C++ for an awful lot
of application programming tasks. It has already happened at Microsoft and
it's only a matter of time for it to happen with the vast majority of
Windows development.

--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA

20% of the world is real.
80% is gobbledygook we make up inside our own heads.

 

[Magnus Lidbom]

actually

You claim that C++ has this wonderful ability that C# and other
OO-languages
lack. Having read your clear example I say DBC can be implemented much,
much nicer and cleaner using events <snip>

No. It most definitely cannot. Private virtuals guarantees that the most
derived override is called once and once only when called from the base
class. Events do no such thing.

<snip>

/Magnus Lidbom

 

[Eric Gunnerson [MS]]

I was going to write a response to this, but Martin said everything I was
going to say, so I'll just say "what Martin said..."

--
Eric Gunnerson

Visit the C# product team at http://www.csharp.net
Eric's blog is at http://weblogs.asp.net/ericgu/

This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Andreas Huber]

It *is* esoteric, and I would wager that the C# language designers
chose simplicity in the interest of industrial robustness.

You seem to suggest that C++s support for private virtual functions makes
C++ less robust. Funny, I'd claim exactly the opposite.

"Industrial robustness" in the real world means simplifying things so
that the vast majority of average programmers understand what's going
on.

Simple: If you don't understand it, don't use it and everything will be
well. If you happen to maintain somebody else's code using the private
virtual idiom it should become obvious very quickly how it works. If not,
post an appropriate question to comp.lang.c++ ;-).
I really fail to see how private virtuals hurt "industrial robustness".

Regards,

Andreas

 

[TT \(Tom Tempelaere\)]

Okay, that makes sense. Technically that is.


Name one .
Martin.

DBC (Design By Contract). Public non-virtual interface (interface), private
virtual interface (implementation). The public interface enforces pre and
post conditions, and delegates implementation to the private virtual
implementation.

Tom.