When you call [SnowTire init] the included [super init] calls [BasicTire init] which in turn calls [NSObject init]? (i.e. a cascade running up to the parent/superclass.
You implement both -[SnowTire init]
and -[BasicTire init]
, so you can just look at your implementations to see that:
- Your
-[SnowTire init]
uses [super init]
to call -[BasicTire init]
.
- Your
-[BasicTire init]
uses [super init]
to call -[NSObject init]
.
[super init]
always calls the next available implementation, even if it's not in your immediate superclass. If you don't implement -[BasicTire init]
, then the [super init]
expression in -[SnowTire init]
will call -[NSObject init]
. That's fine, because you apparently decided that a BasicTire doesn't need any initialization. (If it does, then your omission of -[BasicTire init]
was a mistake.)
When you [SnowTire alloc] you are creating a single new object, that includes the the functionality of its superClass. Am I right in thinking your not creating multiple objects that are linked in some fashion (i.e. SnowTire > BasicTire > NSObject).
Yes. Every object has a class (in a variable named isa
, as in “this instance is a SnowTire”), and every class has a superclass and a metaclass. -alloc
and -init
, like all Objective-C methods and C functions, each only return one thing—in this case, one instance with one class.
So, for example, when you send a gripTheSnow
message to your snow tire, it uses SnowTire's implementation of that method. If you send a retain
message, well, you didn't implement retain
in SnowTire and you didn't implement it in BasicTire, so it uses NSObject's implementation. The runtime searches, starting from the object's class (in this example, SnowTire), in a straight line up the class hierarchy, ending at a root class such as NSObject.