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

[Ken Brady]

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

 

[Guest]

If you plan on them to be derived from then yes obviously.

If its a sealed class, then its pointless and the compiler (if it doesnt)
should prevent having virtuals in a sealed class.

 

[Dag Henriksson]

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.

 

[Magnus Lidbom]

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

 

[n!]

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!

 

[Guest]

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

Does other languages prevent PUBLIC virtuals and only allow protected
virtuals?

 

[TT \(Tom Tempelaere\)]

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.

 

[Dag Henriksson]

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.

 

[Frank Oquendo]

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)

 

[Carl Daniel [VC++ MVP]]

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

 

[Miha Markic]

Hi Carl,

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?

 

[Magnus Lidbom]

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

 

[Dag Henriksson]

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

 

[TT \(Tom Tempelaere\)]

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.

 

[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

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

wrote in message news:[email protected]...

 

[100]

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

B\rgds
100

 

[Frank Oquendo]

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)

 

[Frank Oquendo]

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)

 

[Carl Daniel [VC++ MVP]]

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

 

[Magnus Lidbom]

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