Re: Best practice for overridden initializers in subclasses
Re: Best practice for overridden initializers in subclasses
- Subject: Re: Best practice for overridden initializers in subclasses
- From: Andy Lee <email@hidden>
- Date: Tue, 25 Mar 2008 19:26:52 -0400
A similar question was asked recently. To paraphrase (and slightly
correct) my reply:
I do essentially this:
- (id)init
{
NSLog(@"%@ -- '%@' is not the designated initializer",
[self class],
NSStringFromSelector(_cmd));
[self release];
return nil;
}
You can imagine wrapping the three statements in a macro, and/or
throwing an exception or putting in a breakpoint.
Since there's no way to enforce designated initializers at compile
time, and there may be no way for you to recover gracefully at
runtime, the best you can do is catch the error wherever possible
during development and testing.
--Andy
On Mar 25, 2008, at 6:01 PM, Andy Klepack wrote:
I have a subclass of NSObject that provides its own designated
initializer that allows client code to configure an instance with
initial values. Instances of the class itself are immutable. At the
same time, instances where no initial values are supplied do not
make conceptual sense.
I'm wondering how to deal with overriding the 'init' method of
NSObject. There's really no sensible default values that I could
have init pass along to my designated initializer. It doesn't make
sense for clients to call 'init' and I'm debating whether to return
nil, throw some sort of exception, make the instance 'dead' and
essentially do nothing, or to do something else..
Anyone have a recommendation for the best practice in this case?
-Andy
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden