On page 288 in figure 33.2, there is an arrow from BNRAppliance’s init method to BNROwnedAppliance’s initWithProductName: method. I am guessing this is just a “typo”. It seems like the arrow should point to BNRAppliance’s initWithProductName:. I wouldn’t think that a method of a superclass is going to know about the methods of its subclasses.
My goodness, you’re absolutely correct. Good catch! Here’s an updated version: mw-dropshare.s3.amazonaws.com/c … f8zx5S.png
@MikeyWard I thought you were right the first time because of the context of the diagram:
Quiz time: Do you also need to implement init in BNROwnedAppliance? No. At this point, the following code will work fine:
OwnedAppliance *a = [[OwnedAppliance alloc] init];
Why? There is no implementation of init in BNROwnedAppliance, so this line will trigger the init method implemented in BNRAppliance, which calls
[self initWithProductName:@"Unknown"].selfis an instance of BNROwnedAppliance, so it calls initWithProductName: in BNROwnedAppliance, which calls[self initWithProductName:pn firstOwnerName:nil].
What you wind up with is a chain of initializers that call other initializers.
It seems the reason why BNRAppliance appears to know about initializers of its subclass is because init was called on the subclass in the first place. Because init is not implemented in BNROwnedAppliance, the call moved up the hierarchy looking for an implementation of init.