Re: designated initializer conventions
Re: designated initializer conventions
- Subject: Re: designated initializer conventions
- From: Brendan Younger <email@hidden>
- Date: Sun, 30 Jan 2005 15:56:34 -0600
On Jan 30, 2005, at 4:29 AM, Mike Bolton wrote:
While searching for ways to draw a border around an NSView during a
drag and drop operation, I came across the following message:
http://www.cocoabuilder.com/archive/message/2004/5/5/106346
I was hoping someone could shed some light on exactly how to conform
to the conventions of "designated initializers" in such a case. In
the code from the message, there's only one init method:
- (id) initWithParent: (NSView *) inParent
{
NSRect parentFrame = [inParent frame];
if (self = [self initWithFrame: parentFrame]) {
//do something
}
return self;
}
now, from what I've read in the Objective-C Programming Language
manual (and from
http://developer.apple.com/documentation/Cocoa/Reference/Foundation/
ObjC_classic/Classes/NSObject.html#//apple_ref/doc/uid/20000050/init),
it states that "the subclass is obliged to cover (override) only the
designated initializer of the superclass". I've also read that "The
designated initializer in a class must, through a message to super,
invoke the designated initializer in a super class".
What confuses me is that the above initializer sends the initWithFrame
to self, rather than super.. That would lead me to believe that
initWithFrame is the designated initializer for the class (unless this
is a typo and the initWithFrame should've been sent to super). In
order to conform with the rules mentioned in the previous paragraph,
shouldn't the class implement initWithFrame, which would simply call
"if (self = [super initWithFrame...]", or is this being overly
pedantic, and unnecessary, given that the designated initializer of
the subclass is the same as the superclass, in which case you don't
need to the subclass to override it.
You're correct; initWithFrame is still the designated initializer, even
of the subclass. There's no reason to override initWithFrame since all
it would do is call super's implementation anyway. However, sending
initWithFrame to self rather than super is good practice since then
someone can override initWithFrame (possibly in a subclass) and still
get it called.
Or should initWithParent actually be considered the designated
initializer, since it allows more flexibility in the creation of the
object, and the subclass should thus implement something similar to
the following:
- (id) initWithFrame:(NSRect)aFrame
{ return [self initWithParent:nil]; }
- (id) initWithParent: (NSView *) inParent
{
NSRect parentFrame;
if (inParent == nil)
parentFrame = NSMakeRect (0,0,0,0);
else
parentFrame = [inParent frame];
if (self = [super initWithFrame: parentFrame]) {
//do something
}
return self;
}
Generally speaking, it's not good form to change the designated
initializer midway through the inheritance hierarchy. In this case,
there's really nothing to be gained from making initWithParent the
designated initializer unless the class positively will not work
without a parent view.
In general, the designated initializer is just a convenient construct
to allow subclasses to override a single initialization point; it's not
meant to be an unbreakable contract. If someone really wants to misuse
your class by calling initWithFrame instead of initWithParent, there's
really no reason to keep them from doing so.
Brendan Younger
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden