inheritance
Tony Johansson
I have this inheritance below. My base class is Car and derived from that is
SportCar
When I create an instance of SportCar I assume that I can consider to have
an instance of my Car object
within the instance of SportCar. Does that sound reasonable ?
If we can agree upon that I come to next question.
If I now make the Car class abstract which mean that it's not possible to
have an instance of a Car class.
But when I create an instance of a SportCar does that mean that I can't
assume that I have an instance
of a Car within the SportCar object.
class Car
{
public void Drive()
{
}
}
class SportCar : Car
{
public void Foo()
{
base.Drive();
}
}
//Tony
Arne Vajhøj
> I have this inheritance below. My base class is Car and derived from that is
> SportCar
> When I create an instance of SportCar I assume that I can consider to have
> an instance of my Car object
> within the instance of SportCar. Does that sound reasonable ?
SportCar is a Car and has all the fields and methods of Car.
> If we can agree upon that I come to next question.
>
> If I now make the Car class abstract which mean that it's not possible to
> have an instance of a Car class.
> But when I create an instance of a SportCar does that mean that I can't
> assume that I have an instance
> of a Car within the SportCar object.
Same situation.
SportCar can use all the non-private methods of Car.
Note that if SportCar does not implement all abstract
methods of Car then SportCar will become abstract.
Arne
Scott M.
also have *another* instance of a car as well. There is just one class that
has been instantiated.
So, it Car is abstract, you can't make instances of it, but you can derive a
new class from it and make an instance of that class.
And, if you do derive a new class from an abstract base class, then you
*must* implement all of the base class's abstract members, you don't have a
choice.
-Scott
"Arne Vajh�j" <ar...@vajhoej.dk> wrote in message
news:4ab6a386$0$284$1472...@news.sunsite.dk...
Arne Vajhøj
> "Arne Vajh�j" <ar...@vajhoej.dk> wrote in message
> news:4ab6a386$0$284$1472...@news.sunsite.dk...
>> Tony Johansson wrote:
>>> I have this inheritance below. My base class is Car and derived from that
>>> is SportCar
>>> When I create an instance of SportCar I assume that I can consider to
>>> have an instance of my Car object
>>> within the instance of SportCar. Does that sound reasonable ?
>> SportCar is a Car and has all the fields and methods of Car.
>>
>>> If we can agree upon that I come to next question.
>>>
>>> If I now make the Car class abstract which mean that it's not possible to
>>> have an instance of a Car class.
>>> But when I create an instance of a SportCar does that mean that I can't
>>> assume that I have an instance
>>> of a Car within the SportCar object.
>> Same situation.
>>
>> SportCar can use all the non-private methods of Car.
>>
>> Note that if SportCar does not implement all abstract
>> methods of Car then SportCar will become abstract.
don't
> also have *another* instance of a car as well. There is just one
class that
> has been instantiated.
>
> So, it Car is abstract, you can't make instances of it, but you can
derive a
> new class from it and make an instance of that class.
>
> And, if you do derive a new class from an abstract base class, then you
> *must* implement all of the base class's abstract members, you don't
have a
> choice.
Unless the new class is also abstract!
Arne
Mike Schilling
> Hello!
>
>
> I have this inheritance below. My base class is Car and derived from
> that is SportCar
> When I create an instance of SportCar I assume that I can consider
> to
> have an instance of my Car object
> within the instance of SportCar. Does that sound reasonable ?
Not entirely. Rather, you have an object which you can, if you
choose, treat as a Car. That's why
Car car = new SportCar();
is legal.
> If we can agree upon that I come to next question.
>
> If I now make the Car class abstract which mean that it's not
> possible to have an instance of a Car class.
> But when I create an instance of a SportCar does that mean that I
> can't assume that I have an instance
> of a Car within the SportCar object.
Car car = new SportCar();
works whether Car is abstract or not.
Peter Duniho
wrote:
> [...]
>> If I now make the Car class abstract which mean that it's not
>> possible to have an instance of a Car class.
>> But when I create an instance of a SportCar does that mean that I
>> can't assume that I have an instance
>> of a Car within the SportCar object.
>
> Car car = new SportCar();
>
> works whether Car is abstract or not.
To elaborate:
In an abstract class, the abstract members are implicitly virtual. So,
even though you can't create an instance of the abstract class Car, as
long as you have an instance of a class that inherits Car, it (or an
intermediate class) necessarily has provided implementation for all
abstract members in Car, and since those members are virtual, that
implementation is available through the polymorphism of virtual members.
In fact, it's this polymorphism that makes abstract classes so useful. An
abstract class is a lot like an interface, except that it may (and should,
otherwise it really ought to be an interface) provide at least some basic
implementation useful for classes that will inherit it. And so in the
same way that interfaces are all about polymorphism, that's what makes
abstract classes so interesting. You can implement the abstract class in
multiple ways, always referring to the instances of the implementations by
the abstract class only, and yet still getting the varying behaviors of
those multiple implementations according to what instance you're using.
Whether any of this answers the question the OP is asking, I'm not sure.
The question seems to be as much about conceptualizing the classes
involved as it is about the practical use of them, and all of our answers
have been more about the practical use.
To the OP: I would say that in terms of conceptualizing, whatever makes
the most sense to you and lets you use the OOP techniques most
productively, that would be a good start. For the purpose of this
question, remember that abstract classes act like an interface that
includes some implementation (but not all). So, for the purposes of
conceptualizing the way abstract classes work, I would say you should
think about how you conceptualize interfaces. When you have a class that
implements an interface, you have a type (the interface) that is a subset
of the implementing class, and in that respect the implementing class
might be considered "to have an instance of the interface within the
implementing class".
For example:
interface IHorn
{
void Honk();
}
class Car : IHorn
{
public void Honk()
{
Console.WriteLine("Beep!");
}
}
How do you conceptualize that? Whatever the answer to that question is,
that's _half_ the answer to how you conceptualize an abstract class...that
is, it's the half of the answer that applies to the abstract members of
the abstract class. The other half of the answer is the half that applies
to the non-abstract members, which is the same conceptualization you would
have for any non-abstract base class (i.e. "has an instance of your base
class object within the instance of the derived class").
I can't really answer what the right way for _you_ to conceptualize
abstract classes is, or even inheritance generally. I can tell you that
for me, I don't think so much about containment. Rather, it's more about
the classic "is a" versus "has a" relationship. When a class inherits
another class, it doesn't _contain_ the base class, it _is_ the base
class, as well as something more.
After all, I can be generalized as "animal", "human", "man", and "Pete".
But "Pete" doesn't contain a "man", nor does a "man" contain a human,
etc. Instead, the more specialized descriptions "are" the thing that
comes before them in the hierarchy.
If it works for you to think of the relationships differently, and it
doesn't lead to problems designing your code, that's fine. But IMHO,
thinking of inheritance as a containment relationship can lead to badly
designed class hierarchies, especially when you wind up with one class
inheriting another class that it really _shouldn't_ (i.e. because the
derived class really should just include an instance of the base class by
composition, rather than by inheritance).
Sorry for the essay. I realize your question appeared simple; it's just
that I think in reality, it's deceptively complex and important. I'm not
sure if we stop at simple telling you the mechanics, that's really doing
the question justice.
Pete