macOS Hillegass P 55

[mdeh]

Hi all,
I am just trying to understand what Hillegass means here.

He is talking about designated initializers, and how one should use it if a class has more than one initializer. And how a DI will call it's super's DI if there is one. So far so good.

But then he says

The day will come when you will create a class that must, must ,must have an argument supplied. Override the superclass's designated initializer to throw and exception

And the code to illustrate this is

-(id) init
{
[self dealloc];
@throw [NSException exceptionWithName:@"BNRBadInitCall" reason: yada yada ", userInfo: nil];
return nil;
}

It probably makes a lot more sense to someone other than I, so would like a "clue" as to what it means.

 

[eddietr]

So maybe a (contrived) example would help.

Suppose there is a class Foo that has the normal init intializer. So you can (and should) do:

Foo* someRef = [[Foo alloc] init];

And then suppose you have a subclass Bar : Foo that has a designated initializer initWithCriticalVariable:

So what Hillegass is saying is that you might have a case like Bar where the object cannot function properly without this critical variable. So you always want users to do this:

Bar* someRef = [[Bar alloc] initWithCriticalVariable: someVar];

And you never want to allow them to do this:

Bar* someRef = [[Bar alloc] init];

So the way you prevent the latter in ObjC is to define an init (for Bar) that always returns an error like his sample code shows.

Hope that helps?

 

[lee1210]

It's hard to think of a concrete example for this, so I'll just make something up. There is a class Foo. It is a great class, but you really need a MySuperFoo class that can come in 3 different varieties. The functionality is basically identical for these varieties, but the "flavor" MUST be picked for MySuperFoo. This means that there is no case under which you should be able to initialize a MySuperFoo with init, because you haven't decided what sort of MySuperFoo it is, and such a thing cannot exist.

So what if someone passes init to MySuperFoo and you haven't overridden it? Well, the init method of Foo will get called. Now there's a MySuperFoo without a flavor. Uh oh. So to remedy this, Kochan suggests overriding init and throwing an exception, so it's not even possible to get a MySuperFoo without a flavor.

Hopefully this helps.

-Lee

eddietr beat me to it.

 

[mdeh]

So maybe a (contrived) example would help.

Suppose there is a class Foo that has the normal init intializer


.........


And then suppose you have a subclass Bar : Foo that has a designated initializer initWithCriticalVariable:


.............




And you never want to allow them to do this:

Bar* someRef = [[Bar alloc] init];

Hope that helps?

Yes...that is exactly what he was talking about, but I did not think that was relevant so did not included that.
The way we avoided the init call was to have within the init, a call to the designated initializer

-(id) init
return [ self designaged_Initializer  ............];

I just assumed that this was **always** possible, but as you say, this is just showing what to do if for some reason it is not possible to do the above.

So, thank you for explaining that...it makes perfect sense now.

 

[mdeh]

It's hard to think of a concrete example for this, so I'll just make something up. There is a class Foo. It is a great class, but you really need a MySuperFoo class that can come in 3 different varieties. The functionality is basically identical for these varieties, but the "flavor" MUST be picked for MySuperFoo. This means that there is no case under which you should be able to initialize a MySuperFoo with init, because you haven't decided what sort of MySuperFoo it is, and such a thing cannot exist.

So what if someone passes init to MySuperFoo and you haven't overridden it? Well, the init method of Foo will get called. Now there's a MySuperFoo without a flavor. Uh oh. So to remedy this, Kochan suggests overriding init and throwing an exception, so it's not even possible to get a MySuperFoo without a flavor.

Hopefully this helps.

-Lee

eddietr beat me to it.

Yes...it does. By the way...I have moved on to Hillegas. Hopefully I can continue to consult the **very** knowledgeable and helpful consultants as I move through this book too.

 

[lee1210]

Oops. There's been so many threads from Kochan that i missed that a different author/text was being discussed. Since it's already been quoted it's not worth correcting the above... maybe i should just stick to "the author" =).

-Lee

 

[mdeh]

Oops. There's been so many threads from Kochan that i missed that a different author/text was being discussed. Since it's already been quoted it's not worth correcting the above... maybe i should just stick to "the author" =).

-Lee

Hey...you know what they say about publicity!!!