Inheritance question

[relient]

I am trying to understand the code below but I need some affirmation of
the following first: The reason I inherit the "Base" class method
implementation instead of the "Derived" class method in the class
"Third" is because the class "Derived" method has no implementation
because it's abstract. Am I right? Also, this is the only time this
applies in a chain of derived classes. So if the "Derived" class method
wasn't abstract, then, class "Third" would inherit the "Derived" class
method because a derived class always inherits from the last class.

Also, The placement of the keywords override and abstract in the method
signature in class "Derived" doesn't matter. Right? If they're
switched, It's the same thing (yes?). I personally think it's more
readable the way it's currently set. Switching them makes the signature
confusing to understand. So I don't understand why it was even allowed
in C#. What do you think?


class Base
{
public virtual void DrawYourself()
{
}
}

abstract class Derived : Base
{
public override abstract void DrawYourself( );
}

class Third : Derived
{
public override void DrawYourself( )
{
}
}


Thanks for reading,
Relient.

 

[relient]

Oh, yes... One last thing I forgot to say above (which was my primary
question; hehe) is: override and abstract in the same signature doesn't
make much sense to me. I mean, It's not like you can create an instance
of class "Derived" and assign it to a variable of type class Base, to
use in polymorphism, because it's abstract. I do, however, understand
if it was "new abstract" but, "override abstract"? what's up with that
confusing signature?

 

[Jon Skeet [C# MVP]]

I am trying to understand the code below but I need some affirmation of
the following first: The reason I inherit the "Base" class method
implementation instead of the "Derived" class method in the class
"Third" is because the class "Derived" method has no implementation
because it's abstract. Am I right?

It's not clear what you mean by interiting the base class method
implementation in this context. You're overriding the method, so you're
not actually using any other implementation.

Perhaps you could give some code which (say) printed out different
values in the different implementations, to show what you mean?

Also, this is the only time this
applies in a chain of derived classes. So if the "Derived" class method
wasn't abstract, then, class "Third" would inherit the "Derived" class
method because a derived class always inherits from the last class.

Also, The placement of the keywords override and abstract in the method
signature in class "Derived" doesn't matter. Right? If they're
switched, It's the same thing (yes?).
Yes.

I personally think it's more readable the way it's currently set.
Switching them makes the signature confusing to understand. So I
don't understand why it was even allowed in C#. What do you think?

Modifiers are generally allowed in any order, I believe. I guess it
allows different people do use different conventions for whatever they
find most readable.

 

[Jon Skeet [C# MVP]]

Oh, yes... One last thing I forgot to say above (which was my primary
question; hehe) is: override and abstract in the same signature doesn't
make much sense to me. I mean, It's not like you can create an instance
of class "Derived" and assign it to a variable of type class Base, to
use in polymorphism, because it's abstract. I do, however, understand
if it was "new abstract" but, "override abstract"? what's up with that
confusing signature?

It's not that confusing - it basically means that the derived class
*has* to implement the method, and it's an override so that if someone
has:

Base b = new Third();
b.DrawYourself();

it will still call the overridden method in Third. (If it were "new
abstract" in Derived, the above would call Base.DrawYourself.)

 

[Jay R. Wren]

I am trying to understand the code below but I need some affirmation of
the following first: The reason I inherit the "Base" class method
implementation instead of the "Derived" class method in the class
"Third" is because the class "Derived" method has no implementation
because it's abstract. Am I right? Also, this is the only time this
applies in a chain of derived classes. So if the "Derived" class method
wasn't abstract, then, class "Third" would inherit the "Derived" class
method because a derived class always inherits from the last class.

Also, The placement of the keywords override and abstract in the method
signature in class "Derived" doesn't matter. Right? If they're
switched, It's the same thing (yes?). I personally think it's more
readable the way it's currently set. Switching them makes the signature
confusing to understand. So I don't understand why it was even allowed
in C#. What do you think?


class Base
{
public virtual void DrawYourself()
{
}
}

abstract class Derived : Base
{
public override abstract void DrawYourself( );
}

class Third : Derived
{
public override void DrawYourself( )
{
}
}


Thanks for reading,
Relient.

I think maybe one of the issues is that the above code should not
compile. You have an abstract class inheriting from a concrete class,
which is not allowed. Unless I'm really lost.

 

[Bruce Wood]

I think maybe one of the issues is that the above code should not
compile. You have an abstract class inheriting from a concrete class,
which is not allowed.

An abstract class certainly can inherit from a concrete class. All the
abstract class has to do is declare one or more things abstract. Now,
up to now I had always seen that as the abstract (child) class _adding_
abstract methods or properties that didn't exist in the concrete base
class. I'd never seen an abstract class changing one of the base class
methods from implemented to abstract. However, since Jon says it can
happen, I believe it.

A (conceptually) simpler concrete-to-abstract inheritance situation
might be something like this:

public class ConcreteBase
{
public string BaseProperty { get { ... }}
}

public abstract class AbstractChild : ConcreteBase
{
public abstract int ChildMethod(string param1);
}

Here the child class is clearly abstract because it declares a new
method not in the base class but which is abstract (has no
implementation), so clearly the child class has to be abstract.

 

[Jay R. Wren]

An abstract class certainly can inherit from a concrete class. All the
abstract class has to do is declare one or more things abstract. Now,
up to now I had always seen that as the abstract (child) class _adding_
abstract methods or properties that didn't exist in the concrete base
class. I'd never seen an abstract class changing one of the base class
methods from implemented to abstract. However, since Jon says it can
happen, I believe it.

A (conceptually) simpler concrete-to-abstract inheritance situation
might be something like this:

public class ConcreteBase
{
public string BaseProperty { get { ... }}
}

public abstract class AbstractChild : ConcreteBase
{
public abstract int ChildMethod(string param1);
}

Here the child class is clearly abstract because it declares a new
method not in the base class but which is abstract (has no
implementation), so clearly the child class has to be abstract.

Wow, that is very interesting. After sending the email I realized that
it may be possible if the abstract child class added some new members as
abstract, but this changing operation is very strange. It is nice that
it is possible, but does anyone have a use case for it? I cannot think
of one.

 

[Jon Skeet [C# MVP]]

An abstract class certainly can inherit from a concrete class. All the
abstract class has to do is declare one or more things abstract.

Not even that, quite. The following compiles quite happily:

abstract class Foo
{
}

It's not often useful to make a class abstract without adding any
abstract members, but it's handy every so often. I can't think of an
example offhand...

Now, up to now I had always seen that as the abstract (child) class _adding_
abstract methods or properties that didn't exist in the concrete base
class. I'd never seen an abstract class changing one of the base class
methods from implemented to abstract. However, since Jon says it can
happen, I believe it.

LOL. I can't say I've seen it particularly often, nor can I remember
any examples again.

Jon

 

[relient]

Ok, so, Jon. What this basically means is that if you used 'new'
instead of 'override' in the abstract class, then, you basically killed
polymorphism for a Base reference to a Third class object. Right?

I found this on a search:"why C#'s "abstract-override" is so cool"
http://blogs.msdn.com/jmstall/archive/2005/08/07/abstract_override.aspx
might be more explanatory for those in the same boat as I.

 

[Jon Skeet [C# MVP]]

Ok, so, Jon. What this basically means is that if you used 'new'
instead of 'override' in the abstract class, then, you basically killed
polymorphism for a Base reference to a Third class object. Right?
Yup.

I found this on a search:"why C#'s "abstract-override" is so cool"
http://blogs.msdn.com/jmstall/archive/2005/08/07/abstract_override.aspx
might be more explanatory for those in the same boat as I.

Right. As I say, it doesn't come up often, but every so often it can be
useful.