• Choose a category
• All
• Classic-Fiction

The init method fails, deallocates the object, and returns nil.

To deal with the first case, Apple requires that you set self to point to the object returned from the superclass’s init method. You did this in the first line of your init method.

To deal with the second case, Apple recommends that you check that your superclass’s initializer returns a valid object and not nil. After all, there’s no point in performing custom set-up on an object that doesn’t exist. Change your init method to match Apple’s recommendation:

- (id)init

{

// Call NSObject's init method

self = [super init];

// Did it return something non-nil?

if (self) {

// Give voltage a starting value

voltage = 120;

}

return self;

}

Truthfully, these sorts of checks are only necessary in a couple of very specific cases. Thus, in practice, many Objective-C programmers often skip the extra checks. In this book, however, we will always do the checks because it is the Apple-approved way to implement init methods.

Using accessors

So far you have a perfectly good init method for Appliance, but I want to show you a variation that you will see in other people’s code. I typically do a plain assignment in an init method, but many programmers will use the accessor method. Change your init method to do this:

- (id)init

{

// Call NSObject's init method

self = [super init];

// Did it return something non-nil?

if (self) {

// Give voltage a starting value

[self setVoltage:120];

}

return self;

}

In most cases, there is little reason to do one over the other, but it makes for a great argument. The argument goes like this: The assign guy says, “You can’t use an accessor method in an init method! The accessor assumes that the object is ready for work, and it isn’t ready for work until after the init method is complete.” Then the accessor method guy says, “Oh, come on. In the real world that is almost never an issue. My accessor method might be taking care of other stuff for me. I use my accessor anytime I set that variable.” In reality, either approach will work in the vast majority of cases.

init methods that take arguments

Sometimes an object can’t be initialized properly without some information from the method that is calling it. For example, imagine that an appliance can’t function without a name. (nil doesn’t count.) In this case, you need to be able to pass the initializer a name to use.

You can’t do this with init because, for now and always, init has no arguments. So you have to create a new initializer instead. Then, when another method creates an instance of Appliance, it would look like this:

Appliance *a = [[Appliance alloc] initWithProductName:@"Toaster"];

The new initializer for Appliance is initWithProductName:, and it accepts an NSString as an argument. Declare this new method in Appliance.h:

#import

@interface Appliance : NSObject {

NSString *productName;

int voltage;

}

@property (copy) NSString *productName;

@property int voltage;

- (id)initWithProductName:(NSString *)pn;

@end

In Appliance.m, find the implementation of init. Change the name of the method to initWithProductName: and set productName using the passed-in value.

- (id)initWithProductName:(NSString *)pn

{

// Call NSObject's init method

self = [super init];

// Did it return something non-nil?

if (self) {

// Set the product name

[self setProductName:pn];

// Give voltage a starting value

[self setVoltage:120];

}

return self;

}

Before you continue, build the project to make sure the syntax is right.

Now you can create an instance of Appliance with a given name. However, if you give Appliance.h and Appliance.m to another programmer, she may not realize she needs to call initWithProductName:. What if she creates an instance of Appliance in the most common way?

Appliance *a = [[Appliance alloc] init];

This is not an unreasonable action. As a subclass of NSObject, an instance Appliance is expected to do anything an instance