A
Adrian Herscu
Hi all,
In which circumstances it is appropriate to declare methods as non-virtual?
Thanx,
Adrian.
In which circumstances it is appropriate to declare methods as non-virtual?
Thanx,
Adrian.
non-virtual?Adrian Herscu said:Hi all,
In which circumstances it is appropriate to declare methods as
Adrian Herscu said:In which circumstances it is appropriate to declare methods as non-virtual?
Horatiu Ripa said:Anytime you want that the base class method to remain unchanged by
overwriting it in inheritors.
I presume you came from Java where all the methods are virtual by
default, anyway it adds some clarity to the code.
Adrian Herscu said:You almost guess it right! I learn Java a few days before, and it says that
it is C++ cleaned up. As far as I remember, C++ has virtual and non-virtual
method declarations and now I see that C# continued that tradition. But, I
want to understand the essence of it - why non-virtual methods are needed?
Java is used almost ten years without non-virtual methods and nobody
complains about!
Jon Skeet said:Java *does* have non-virtual methods (they're called final in Java).
Look at Object.wait() for example.
andrew queisser said:One common use is with the "Template Method" pattern:
the base class declares a public non-virtual function which
checks preconditions, calls a protected or private virtual
function, then checks postconditions, like so:
(F is non-virtual, DoF is protected virtual and probably abstract)
int base::F(int i)
{
int ret;
if (IsParamInRange(i))
ret = DoF(i);
if (IsRetInRange(ret))
return ret;
else
return someError;
}
The idea is to force everyone to use a common "entry point"
to some functionality with derived classes implementing specific
tasks.
Andrew
Adrian Herscu said:I think you are wrong. Read the Java Language Specification, para 8.4.3.3:
"A method can be declared final to prevent subclasses from overriding or
hiding it. It is a compile-time error to attempt to override or hide a final
method".
A final method in Java is close to a sealed method in C# - it prevents
further overriding.
In Java, methods can be hidden only by static methods - so, Java has no
concept of non-virtual methods.
While in C#, methods can be hidden because they were not marked virtual -
so, in order to be sealed a method has to be virtual.
Jon Skeet said:And that, as far as I'm concerned, is the principal feature of being
non-virtual.
No, it has no concept of instance methods hiding other instance
methods, which I view as being separate from having no concept of non-
virtual methods.
In my view, they can be sealed to prevent them being virtual any
further.
My way of looking at things is that something is virtual if it can be
overridden, and is non-virtual if it can't.
It's all a matter of definition, of course, but mine seems to fit in
pretty well with this section from the MSDN on virtual members:
<quote>
The virtual keyword is used to modify a method or property declaration,
in which case the method or the property is called a virtual member.
The implementation of a virtual member can be changed by an overriding
member in a derived class.
When a virtual method is invoked, the run-time type of the object is
checked for an overriding member. The overriding member in the most
derived class is called, which might be the original member, if no
derived class has overridden the member. (For more information on run-
time type and most derived implementation, see 10.5.3 Virtual methods.)
By default, methods are non-virtual. You cannot override a non-virtual
method.
</quote>
Here's another one, from the C# language specification:
<quote>
The implementation of a non-virtual method is invariant: The
implementation is the same whether the method is invoked on an instance
of the class in which it is declared or an instance of a derived class.
In contrast, the implementation of a virtual method can be superseded
by derived classes.
</quote>
A final method in Java absolutely satisfies the descriptions of non-
virtual methods above. Note that in neither of those two quotes is
hiding of methods mentioned.
I don't know how is in JAVA, but if you assert here that declaring a methodAnd that, as far as I'm concerned, is the principal feature of being
non-virtual.
In my view, they can be sealed to prevent them being virtual any
further.
My way of looking at things is that something is virtual if it can be
overridden, and is non-virtual if it can't.
It's all a matter of definition, of course, but mine seems to fit in
pretty well with this section from the MSDN on virtual members:
<quote>
The virtual keyword is used to modify a method or property declaration,
in which case the method or the property is called a virtual member.
The implementation of a virtual member can be changed by an overriding
member in a derived class.
When a virtual method is invoked, the run-time type of the object is
checked for an overriding member. The overriding member in the most
derived class is called, which might be the original member, if no
derived class has overridden the member. (For more information on run-
time type and most derived implementation, see 10.5.3 Virtual methods.)
By default, methods are non-virtual. You cannot override a non-virtual
method.
</quote>
Here's another one, from the C# language specification:
<quote>
The implementation of a non-virtual method is invariant: The
implementation is the same whether the method is invoked on an instance
of the class in which it is declared or an instance of a derived class.
In contrast, the implementation of a virtual method can be superseded
by derived classes.
</quote>
A final method in Java absolutely satisfies the descriptions of non-
virtual methods above. Note that in neither of those two quotes is
hiding of methods mentioned.
I don't know how is in JAVA, but if you assert here that declaring a methodAnd that, as far as I'm concerned, is the principal feature of being
non-virtual.
In my view, they can be sealed to prevent them being virtual any
further.
My way of looking at things is that something is virtual if it can be
overridden, and is non-virtual if it can't.
It's all a matter of definition, of course, but mine seems to fit in
pretty well with this section from the MSDN on virtual members:
<quote>
The virtual keyword is used to modify a method or property declaration,
in which case the method or the property is called a virtual member.
The implementation of a virtual member can be changed by an overriding
member in a derived class.
When a virtual method is invoked, the run-time type of the object is
checked for an overriding member. The overriding member in the most
derived class is called, which might be the original member, if no
derived class has overridden the member. (For more information on run-
time type and most derived implementation, see 10.5.3 Virtual methods.)
By default, methods are non-virtual. You cannot override a non-virtual
method.
</quote>
Here's another one, from the C# language specification:
<quote>
The implementation of a non-virtual method is invariant: The
implementation is the same whether the method is invoked on an instance
of the class in which it is declared or an instance of a derived class.
In contrast, the implementation of a virtual method can be superseded
by derived classes.
</quote>
A final method in Java absolutely satisfies the descriptions of non-
virtual methods above. Note that in neither of those two quotes is
hiding of methods mentioned.
Horatiu Ripa said:I can't give you a good explanation of that. Especially because you can
"overwrite" a method even if it is not declared virtual in the base class
(by declaring a method with the same name an params in the child with "new")
and having the same behaviour. Probably the binding mechanisms take some
advantages of it, but it is just a supposition, I didn't explore this issue.
Another questions is "why not?". Anyhow I find it good as long as the code
is more readable and understandable, when you see the "override" keyword in
a method decalaration it is clear that it overrides/implements a method of a
base class.
Where?
1. In polymorphic structures, where the base class contains some common
behaviour/property that is the same for the derrived classes i.e.:
- shape (base) with circle, square, triangle (derrived): a setColor() method
is the same for all the shapes
2. In classes that contains general behaviours, when you want the derrived
classes only to extend the behaviours and not to change any of the base
behaviours i.e.:
- humanBeing (base) that contains goToSleep(), awake(), walk(), jump(),
stay(); women derrived from humanBeing that contains talkTooMuch(),
spendMensIncome() and man that contains watchAllSportAtTV(),
seekOtherWomen() and so on... )
Anyhow you can do that explicitly by marking the methods as "sealed", and ,
as I already wrote, you can trick that.
Adrian Herscu said:No - the principal feature of being non-virtual, is that non-virtual methods
are resolved at compile-time (a.k.a. static or early binding), so a call
*always* executes the same implementation.
Think again. *Only* non-virtual methods can be "hidden".
"...virtual any further" = "...overriden any further"
Yes.
OK - but you can still hide it.
A final method in Java absolutely does *not* satisfy the descriptions of
non-virtual methods above - simply because you cannot hide it as you can in
C#.
Moreover, even a C# "sealed" method which is the most close to a Java
"final" method, can be hidden by further subclasses
There are two separate notions:
1) Overriding - by overriding, a subclass replaces method pointers in
object's v-table and since all method invokations are made through that
v-table, you will always get the overriding implementation no matter from
which site you call it (either from superclass' site or from subclass'
site) - hence, dynamic binding. Also, that's the reason for naming those
methods "virtual" - because their implementation is not known until
run-time.
2) Hidding - this is a totally different mechanism: method invokations are
resolved during compile-time (static binding); so, there is no v-table to go
through - the call is direct.
In summary: when you call a non-virtual method, you will _always_ get the
same implementation executed; when you call a virtual method, you will *not*
always get the same implementation executed - it depends on the overriding
subclasses.
//++ run this test ++++++
I don't know how is in JAVA, but if you assert here that declaring a method
as *sealed* si the same as declaring non-virtual method you are wrong. Such
a method is still virtulal.
A a = new C()
a.f() calls C.f()
Isn't it virtual?
If it wasn't it would call A.f()
*sealed* modifier force you to stop using overriden until you don't use
*virtual* again and then you can continue override the method.
BTW the
compiler generates *callvirt* instruction as a evidence of that the method
is indeed *virtual*
In c# you can keep going with overrideing the method which was sealed.
what
you have to is to declared it as virtual again(to start new virtual
implemetation).
That is posible because when CLR decides, which is most-derived method it
doesn't take into account only the runtime type of the object it kind of
takes into account the type of the variable as well.
To be more strict
callvirt is provided with the name of the class from where to start looking
for the most-derived implementation.
When you put *sealed* modifier for a method you have to put override as well
(other wise it does'n make sence to prohibit overriding of something which
cannot be overrided anyway).
The modifier *override* already means that the method is virtual.
If you read further down the same section you will find example of hiding
virtual methods, which is more closely to what happend when you declare a
method as a *sealed*. *sealed* modifier just force you to hide the method if
you want to change the implementation.
If *final* in JAVA means that the method cannod be overriden or hid then it
is different form the non-virtual methods.
Non-virtual methods cannot be overriden - OK. One can hide then, though.
So my question is: Why C# allows virtual methods to be hidden. Isn't it
error prone.
I believe that the best is:
1. To have virtual and non-virtual methods.
2. Sealing virtual methods has to prevent further overriding and hiding the
methods.
And actually I think I know the answer. It is side efect of the way the CLR
resolves wich is the most-derived method. .NET is cross langage platform and
if C# was preventing this using calsses written in other languges (allowing
hiding virtual methods) would put C# programmers to consfusion.
Jon Skeet said:And that, as far as I'm concerned, is the principal feature of being
non-virtual.
Eric Gunnerson said: