about abstract class and override

[Tony Johansson]

Hello!

Here I have an Interface called ITest and a class called MyClass which
derive this intrface.
As you can see I don't implement this method myTest in class MyClass because
i use the keyword abstract.
I have also another class called MyDerivedClass which is a sublass to
MyClass.

Now to my question when I implement this method myTest in class
MyDerivedClass I must use
the keyword override. I just wonder I have always used this override when
having a virtual method with the same signature in the base class. Can
somebody explain the reson for this using of override?

public interface ITest
{
void myTest();
}

abstract public class MyClass : ITest
{
abstract public void myTest;
...
}

public class MyDerivedClass : MyClass
{
public override void myTest()
{
}
}

//Tony

 

[Jon Skeet [C# MVP]]

Here I have an Interface called ITest and a class called MyClass which
derive this intrface.
As you can see I don't implement this method myTest in class MyClass because
i use the keyword abstract.
I have also another class called MyDerivedClass which is a sublass to
MyClass.

Now to my question when I implement this method myTest in class
MyDerivedClass I must use
the keyword override. I just wonder I have always used this override when
having a virtual method with the same signature in the base class. Can
somebody explain the reson for this using of override?

myTest *is* a virtual method - just one with no implementation.

Abstract impllies virtual - the method needs to be looked up at
execution time, because there's no way of knowing which implementation
will be used based on the base class reference.

 

[qglyirnyfgfo]

Still kind of weird that you have to use the “override” keyword on
abstract method do you think?

I mean, abstract methods have no implementation whatsoever, they are
just like interfaces but you don’t implement an interface method by
using the “override” keyword.

So the question is. Why force using the override keyword on abstract
methods? Why not just treat this abstract method like interface
methods and use the same syntax when implementing the method on the
derived class?

Do I think this is a big deal? No, I honestly don’t really care how
you have to implement this, I am simply curious.

Cheers

 

[Rudy Velthuis]

Still kind of weird that you have to use the “override” keyword on
abstract method do you think?

I mean, abstract methods have no implementation whatsoever, they are
just like interfaces but you don’t implement an interface method by
using the “override” keyword.

So the question is. Why force using the override keyword on abstract
methods? Why not just treat this abstract method like interface
methods and use the same syntax when implementing the method on the
derived class?

Why should the simple system that if you override a virtual function
you must use "override", have a different syntax for virtual functions
that are overridden, but appear to be abstract in the base class?

What if you refactor your code and decide to put some code in the
originally abstract function after all?

 

[Jon Skeet [C# MVP]]

Still kind of weird that you have to use the =3Foverride=3F keyword on
abstract method do you think?

Absolutely not. It's a definitely good thing - it means you don't
accidentally provide an implementation for an abstract method. Consider
this:

Version 1:
public abstract class Base
{
public abstract void FirstMethod();
}

public class Derived : Base
{
public override void FirstMethod() { /* Implementation */ }

public void SecondMethod() { /* Implementation */ }
}


Version 2:

public abstract class Base
{
public abstract void FirstMethod();
public abstract void SecondMethod();
}

public class Derived : Base
{
public override void FirstMethod() { /* Implementation */ }

public void SecondMethod() { /* Implementation */ }
}

Note how Base now has a method called SecondMethod. Derived should
*not* compile now. It shouldn't silently be implementing an abstract
method without the developer realising - the contract for
Base.SecondMethod might be *completely* different to the meaning of
Derived.SecondMethod.

I mean, abstract methods have no implementation whatsoever, they are
just like interfaces but you don=3Ft implement an interface method by
using the =3Foverride=3F keyword.

This is true, but perhaps unfortunate. I suspect people are a little
bit more wary of introducing new methods in interfaces than they are of
introducing new abstract methods in classes. Maybe.

So the question is. Why force using the override keyword on abstract
methods? Why not just treat this abstract method like interface
methods and use the same syntax when implementing the method on the
derived class?

Do I think this is a big deal? No, I honestly don=3Ft really care how
you have to implement this, I am simply curious.

Given the above, I think it's interface implementation which is
"wrong" here, rather than abstract method implementation.

Hope that's given you a little something to think about - it certainly
has for me

 

[qglyirnyfgfo]

No question, I agree with you and Rudy, I rather be forced to use
override than not since it provides me with a layer of protection in
case I indivertibly do something I didn’t mean to do.

The only thing that bugs me a little is the word “override” since you
are not really overriding anything since there is nothing to override
on an abstract method/property (they are empty and you can’t do things
like calling base.xxxxx etc from them).

Maybe a keyword such as “Implement” would be nicer. Then you could use
that keyword when implementing abstract member as well as interface
members and make the purpose of your method official that way.

Anyway, I have to admit, a lot of the times I just post just to get
your reaction, its always interesting to see what you have to say.

Cheers.
Rene