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