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

There are very good reasons for not making a method virtual unless it needs
to be. That's why virtual is not the default in C#.
Here's Anders Hejlsberg's( the lead C# architect ) take:
http://www.artima.com/intv/nonvirtual.html

/Magnus Lidbom

"Ken Brady" <Ke***********@thomson.com> wrote in message
news:O$**************@TK2MSFTNGP12.phx.gbl...

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?

Thanks in advance....

Nov 15 '05 #4

Not public no, protected only.should be virtual in my view.

Does other languages prevent PUBLIC virtuals and only allow protected
virtuals?
"Dag Henriksson" <da************@hotmail.com> wrote in message
news:bv************@ID-200546.news.uni-berlin.de...

"Ken Brady" <Ke***********@thomson.com> skrev i meddelandet
news:O$**************@TK2MSFTNGP12.phx.gbl...
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?

In fact, most experts think the opposite: "No public member functions

should be virtual".

A class exposes two interfaces, a calling interface (public functions) and a derivation interface (virtual functions). They have different purpose and
different users and should be separate.

--
Dag Henriksson

Nov 15 '05 #5

> If its a sealed class, then its pointless and the compiler (if it doesnt)

should prevent having virtuals in a sealed class.

FWIW the compiler will emit an error if you try to declare a new virtual
method within a sealed class (it will also give a warning about new
protected methods in a sealed class).

n!

Nov 15 '05 #6

TT $Tom Tempelaere$

"Ken Brady" <Ke***********@thomson.com> wrote in message
news:O$**************@TK2MSFTNGP12.phx.gbl...

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?

Thanks in advance....

Mmmm.

I prefer the statement, "all virtual functions should be private", or the
milder "all virtual functions should at least be protected". That does not
include the destructor.

But that does not rule out public virtual functions.

Only functions that were designed to be virtual, should be virtual.

Tom.

Nov 15 '05 #7

Dag Henriksson

<di********@discussion.microsoft.com> skrev i meddelandet
news:Og**************@TK2MSFTNGP10.phx.gbl...

Not public no, protected only.should be virtual in my view.

I prefer ususally 'private virtual', and I only use 'protected virtual' if I
have a good reason to.

--
Dag Henriksson

Nov 15 '05 #8

Dag Henriksson wrote:

I prefer ususally 'private virtual', and I only use 'protected
virtual' if I have a good reason to.

A private method cannot be derived so what's the point of marking it
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)

Nov 15 '05 #9

Frank Oquendo wrote:

Dag Henriksson wrote:
I prefer ususally 'private virtual', and I only use 'protected
virtual' if I have a good reason to.

A private method cannot be derived so what's the point of marking it
virtual?

A private method most certainly CAN be overridden in a derived class. It
simply can'y be CALLED from outside the class where it's first declared.

In the "private virtual" paradigm, an abstract base class exposes a
non-virtual public interface. These non-virtual functions check and inforce
the invariants of the class's interface (look up "design by contract" if
that doesn't ring a bell), and delegate to private virtual methods to
perform the "meat" of the operations. Derived classes can override the
virtual methods to tune the behavior of the class, but since only the base
class's non-virtual interface is public, everyone, including derived
classes, must go through the base interface to access the class (ensuring
that there are no holes in the invariant checking).

-cd

Nov 15 '05 #10

Miha Markic

Hi Carl,

"Carl Daniel [VC++ MVP]" <cp*****************************@mvps.org.nospam >
wrote in message news:O7**************@TK2MSFTNGP09.phx.gbl...

Frank Oquendo wrote:
Dag Henriksson wrote:
I prefer ususally 'private virtual', and I only use 'protected
virtual' if I have a good reason to.

A private method cannot be derived so what's the point of marking it
virtual?

A private method most certainly CAN be overridden in a derived class. It
simply can'y be CALLED from outside the class where it's first declared.

Not in C#. It can't be even declared as private virtual.
Or did I miss the meaning of your post?

--
Miha Markic - RightHand .NET consulting & software development
miha at rthand com
www.rthand.com

Nov 15 '05 #11

Be aware that this thread is cross posted across newsgroups where
the topical languages have different sematics on virtual private methods.
In C# it's disallowed. I dont know why. The code below fails to compile with
the error: "virtual or abstract members cannot be private"

namespace CSharp
{
public class Base
{
private virtual void Test(){}
}

public abstract class Child : Base
{
private override void Test(){}
}
}

Regards /Magnus Lidbom
"Carl Daniel [VC++ MVP]" <cp*****************************@mvps.org.nospam >
wrote in message news:O7**************@TK2MSFTNGP09.phx.gbl...

Frank Oquendo wrote:
Dag Henriksson wrote:
I prefer ususally 'private virtual', and I only use 'protected
virtual' if I have a good reason to.
A private method cannot be derived so what's the point of marking it
virtual?

A private method most certainly CAN be overridden in a derived class. It
simply can'y be CALLED from outside the class where it's first declared.

In the "private virtual" paradigm, an abstract base class exposes a
non-virtual public interface. These non-virtual functions check and

inforce the invariants of the class's interface (look up "design by contract" if
that doesn't ring a bell), and delegate to private virtual methods to
perform the "meat" of the operations. Derived classes can override the
virtual methods to tune the behavior of the class, but since only the base
class's non-virtual interface is public, everyone, including derived
classes, must go through the base interface to access the class (ensuring
that there are no holes in the invariant checking).

-cd

Nov 15 '05 #12

Dag Henriksson

"Frank Oquendo" <fr****@acadxpin.com> skrev i meddelandet
news:OH**************@TK2MSFTNGP10.phx.gbl...

A private method cannot be derived so what's the point of marking it
virtual?

Maybe not in C#, but it certainly can in C++ (this thread is cross-posted to
both groups).

--
Dag Henriksson

Nov 15 '05 #13

TT $Tom Tempelaere$

"Magnus Lidbom" <ma***********@hotmail.com> wrote in message
news:bv************@ID-204195.news.uni-berlin.de...

Be aware that this thread is cross posted across newsgroups where
the topical languages have different sematics on virtual private methods.
In C# it's disallowed. I dont know why. The code below fails to compile with the error: "virtual or abstract members cannot be private"
That is a very weird decision, and I would like to hear the rationale behind
that.

Tom.
namespace CSharp
{
public class Base
{
private virtual void Test(){}
}

public abstract class Child : Base
{
private override void Test(){}
}
}

Regards /Magnus Lidbom
"Carl Daniel [VC++ MVP]" <cp*****************************@mvps.org.nospam >
wrote in message news:O7**************@TK2MSFTNGP09.phx.gbl...
Frank Oquendo wrote:
Dag Henriksson wrote:

> I prefer ususally 'private virtual', and I only use 'protected
> virtual' if I have a good reason to.

A private method cannot be derived so what's the point of marking it
virtual?

A private method most certainly CAN be overridden in a derived class. It simply can'y be CALLED from outside the class where it's first declared.

In the "private virtual" paradigm, an abstract base class exposes a
non-virtual public interface. These non-virtual functions check and

inforce
the invariants of the class's interface (look up "design by contract" if
that doesn't ring a bell), and delegate to private virtual methods to
perform the "meat" of the operations. Derived classes can override the
virtual methods to tune the behavior of the class, but since only the base class's non-virtual interface is public, everyone, including derived
classes, must go through the base interface to access the class (ensuring that there are no holes in the invariant checking).

-cd

Nov 15 '05 #14

Miha Markic

Hi TT,

I guess because private is private to class and not only to outside world.
It makes sense to me..coming from C#.

--
Miha Markic - RightHand .NET consulting & software development
miha at rthand com
www.rthand.com

"TT (Tom Tempelaere)" <_N**************@hotmail.comMAPSO_N_> wrote in
message news:da*******************@phobos.telenet-ops.be...

"Magnus Lidbom" <ma***********@hotmail.com> wrote in message
news:bv************@ID-204195.news.uni-berlin.de...
Be aware that this thread is cross posted across newsgroups where
the topical languages have different sematics on virtual private methods.
In C# it's disallowed. I dont know why. The code below fails to compile with
the error: "virtual or abstract members cannot be private"

That is a very weird decision, and I would like to hear the rationale

behind that.

Tom.
namespace CSharp
{
public class Base
{
private virtual void Test(){}
}

public abstract class Child : Base
{
private override void Test(){}
}
}

Regards /Magnus Lidbom
"Carl Daniel [VC++ MVP]" <cp*****************************@mvps.org.nospam > wrote in message news:O7**************@TK2MSFTNGP09.phx.gbl...
Frank Oquendo wrote:
> Dag Henriksson wrote:
>
>> I prefer ususally 'private virtual', and I only use 'protected
>> virtual' if I have a good reason to.
>
> A private method cannot be derived so what's the point of marking it
> virtual?

A private method most certainly CAN be overridden in a derived class.

It simply can'y be CALLED from outside the class where it's first declared.
In the "private virtual" paradigm, an abstract base class exposes a
non-virtual public interface. These non-virtual functions check and

inforce
the invariants of the class's interface (look up "design by contract" if that doesn't ring a bell), and delegate to private virtual methods to
perform the "meat" of the operations. Derived classes can override the virtual methods to tune the behavior of the class, but since only the base class's non-virtual interface is public, everyone, including derived
classes, must go through the base interface to access the class (ensuring that there are no holes in the invariant checking).

-cd

Nov 15 '05 #15

100

Carl,
C# doesn't support private and virtual methods.

B\rgds
100

"Carl Daniel [VC++ MVP]" <cp*****************************@mvps.org.nospam >
wrote in message news:O7**************@TK2MSFTNGP09.phx.gbl...

Frank Oquendo wrote:
Dag Henriksson wrote:
I prefer ususally 'private virtual', and I only use 'protected
virtual' if I have a good reason to.
A private method cannot be derived so what's the point of marking it
virtual?

A private method most certainly CAN be overridden in a derived class. It
simply can'y be CALLED from outside the class where it's first declared.

In the "private virtual" paradigm, an abstract base class exposes a
non-virtual public interface. These non-virtual functions check and

inforce the invariants of the class's interface (look up "design by contract" if
that doesn't ring a bell), and delegate to private virtual methods to
perform the "meat" of the operations. Derived classes can override the
virtual methods to tune the behavior of the class, but since only the base
class's non-virtual interface is public, everyone, including derived
classes, must go through the base interface to access the class (ensuring
that there are no holes in the invariant checking).

-cd

Nov 15 '05 #16

Carl Daniel [VC++ MVP] wrote:

A private method most certainly CAN be overridden in a derived class.
It simply can'y be CALLED from outside the class where it's first
declared.

Not in C#. Private makes a member accessible to the defining class alone.
Protected makes it accessible to derived classes.

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

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

Nov 15 '05 #17

TT (Tom Tempelaere) wrote:

That is a very weird decision, and I would like to hear the rationale
behind that.

Private is just that: private to the defining type. It works the same way in
Java. It also makes the class design quite obvious as members intended for
use in derived classes are marked protected, not private. I find that level
of granularity to be quite straightforward and very useful.

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

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

Nov 15 '05 #18

Miha Markic wrote:

A private method most certainly CAN be overridden in a derived
class. It simply can'y be CALLED from outside the class where it's
first declared.

Not in C#. It can't be even declared as private virtual.
Or did I miss the meaning of your post?

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).

-cd

Nov 15 '05 #19

Carl Daniel [VC++ MVP] wrote:

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)

Nov 15 '05 #20

"Frank Oquendo" <fr****@acadxpin.com> wrote in message
news:eW*************@TK2MSFTNGP12.phx.gbl...

TT (Tom Tempelaere) wrote:
That is a very weird decision, and I would like to hear the rationale
behind that.
Private is just that: private to the defining type. It works the same way

in Java.
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#.

/Magnus Lidbom

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

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

Nov 15 '05 #21

Magnus Lidbom wrote:

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)

Nov 15 '05 #22

> 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!

Nov 15 '05 #23

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

"Dag Henriksson" <da************@hotmail.com> wrote in message
news:bv************@ID-200546.news.uni-berlin.de...

<di********@discussion.microsoft.com> skrev i meddelandet
news:Og**************@TK2MSFTNGP10.phx.gbl...
Not public no, protected only.should be virtual in my view.
I prefer ususally 'private virtual', and I only use 'protected virtual' if

I have a good reason to.

--
Dag Henriksson

Nov 15 '05 #24

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

"Ken Brady" <Ke***********@thomson.com> wrote in message
news:O$**************@TK2MSFTNGP12.phx.gbl...

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?

Thanks in advance....

Nov 15 '05 #25

Frank Oquendo wrote:

Carl Daniel [VC++ MVP] wrote:
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.

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

Nov 15 '05 #26

.. wrote:

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

Nov 15 '05 #27

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.

Nov 15 '05 #28

Carl Daniel [VC++ MVP] wrote:

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)

Nov 15 '05 #29

> 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.

Nov 15 '05 #30

Frank Oquendo wrote:

Carl Daniel [VC++ MVP] wrote:
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?

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.

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.

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

-cd

Nov 15 '05 #31

Jon Skeet [C# MVP]

Carl Daniel [VC++ MVP]
<cp*****************************@mvps.org.nospam > wrote:

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.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Nov 15 '05 #32

Martin Maat [EBL] wrote:

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 :-).

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

Nov 15 '05 #33

Jon Skeet [C# MVP] wrote:

Carl Daniel [VC++ MVP]
<cp*****************************@mvps.org.nospam > wrote:
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

Nov 15 '05 #34

Brandon J. Van Every

n! wrote:

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.

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.

Nov 15 '05 #35

> > Okay, that makes sense. Technically that is.

there are times when it's useful.
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.

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.

Nov 15 '05 #36

"Martin Maat [EBL]" <du***@somewhere.nl> wrote in message
news:10*************@corp.supernews.com...

Okay, that makes sense. Technically that is.

> there are times when it's useful.

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.

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

Nov 15 '05 #37

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.
"Martin Maat" <du***@somewhere.nl> wrote in message
news:10*************@corp.supernews.com...

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.

Nov 15 '05 #38

Andreas Huber

Brandon J. Van Every wrote:

n! wrote:
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.

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

Nov 15 '05 #39

TT $Tom Tempelaere$

"Martin Maat [EBL]" <du***@somewhere.nl> wrote in message
news:10*************@corp.supernews.com...

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 :-).
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.

Nov 15 '05 #40

> > 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.

The point is to have the client implement alternative behavior. That is what
an event provides. I speak of client and not of derived class since
inheritence does not apply once we choose to use an event instead of a
sub-class to achieve our goal. You can still subclass and implement the new
behavior on any class-level you choose, that is the same as with the private
virtual method.

The (base) class would switch to either the default implementation (Carl's
virtual void part_b()) or the event implementation provided by the client,
depending on whether the event were implemented or not.

If the given example is the best reason to use private virtual methods, it
is really abusing polymorphism to implement an event mechanism. I am not
saying that polymorphism and events are equivalent, I am saying that the
example provided by Carl is a good example of when you should not use
polymorphism if you do have a more natural alternative like events
(delegates in C#).

Polymorphism and inheritence go hand in hand. If you want the polymorphism
part but you do not want the inheritence then you are really saying "this
mechanism is not really suited for my needs but that's okay, I'll cripple
the part that I don't need". It is like using an integer as a boolean.
:-))))))))).

Martin.

Nov 15 '05 #41

Brian Ross

"Carl Daniel [VC++ MVP]" <cp*****************************@mvps.org.nospam >
wrote in message news:#3**************@TK2MSFTNGP10.phx.gbl...

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.

Is it not already possible for derived classes to invoke those functions
anyways. It is a function that belongs to derived afterall? For example:

class Base
{
private:
virtual void f() = 0;
};

class Derived : public Base
{
public:
void g()
{ f(); }

private: // or whatever

virtual void f()
{}

};

I don't see how whether the base class having f() as private or protected
makes any difference to Derived? Additionally, whether 'f()' is protected or
private will make no difference to non-derived classes - it will be
inaccessable.

Whether 'f()' is protected or private _will_ make a difference if any
derived class tries to call 'f()' statically ( ie.. Base::f() ). If it was
private, it would fail.

Brian

Nov 15 '05 #42

One thing that the industry needs a clean up on is Ego and Arrogance.

Look at linux for a start.

"Brandon J. Van Every" <reverse it com dot indiegamedesign at vanevery>
wrote in message news:eL**************@TK2MSFTNGP11.phx.gbl...

n! wrote:
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.

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.

Nov 15 '05 #43

You call having to DUPLICATE method signitures (prototypes) as good coding?
Its to make up for the bad design in the compilers.

These days our Tools work for us not we work for them. Welcome to the REAL
world.
"Andreas Huber" <ah****@gmx.net> wrote in message
news:40**********@news.bluewin.ch...

Brandon J. Van Every wrote:
n! wrote:
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.

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

Nov 15 '05 #44

> 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".

The general point Brandon is making is that in C++ you will easily "use" a
lot of nifty features that you do not understand without being aware of it,
it is unfornunately not a choice in many cases (no pun intended). That has
been acknowledged by the C# designers.

In the private virtual discussion, robustness may not be an issue. I would
call it "not elegant".
Every time something new comes along the established lot will say "Kid's
stuff, no gain, too slow, don't need it". And after a while we all learn to
appreciate it.

And oh (I almost forgot): "my language is better than yours".

Martin.

Nov 15 '05 #45