Hillegass P 55

Discussion in 'Mac Programming' started by mdeh, Mar 7, 2009.

  1. macrumors 6502

    Joined:
    Jan 3, 2009
    #1
    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
    And the code to illustrate this is

    Code:
    -(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.
     
  2. macrumors 6502a

    Joined:
    Oct 29, 2006
    Location:
    Virginia
    #2
    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:

    Code:
    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:

    Code:
    Bar* someRef = [[Bar alloc] initWithCriticalVariable: someVar];
    
    And you never want to allow them to do this:

    Code:
    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?
     
  3. macrumors 68040

    lee1210

    Joined:
    Jan 10, 2005
    Location:
    Dallas, TX
    #3
    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.
     
  4. thread starter macrumors 6502

    Joined:
    Jan 3, 2009
    #4
    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

    Code:
    -(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.
     
  5. thread starter macrumors 6502

    Joined:
    Jan 3, 2009
    #5
    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.:)
     
  6. macrumors 68040

    lee1210

    Joined:
    Jan 10, 2005
    Location:
    Dallas, TX
    #6
    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
     
  7. thread starter macrumors 6502

    Joined:
    Jan 3, 2009
    #7
    Hey...you know what they say about publicity!!! :D
     

Share This Page