Re: alternate pattern for object initializers
Re: alternate pattern for object initializers
- Subject: Re: alternate pattern for object initializers
- From: Michael Gardner <email@hidden>
- Date: Mon, 26 May 2008 02:59:39 -0500
- Domainkey-status: no signature
I would make the most specific initializer the designated initializer
(in your case, have -init call -initWithProperty: instead of the other
way around). It's more efficient, since you don't end up setting the
same properties twice; and there's less redundant code for the same reason.
-Michael
Stuart Malin wrote:
> I am reasonably new to Cocoa. I do have the concept of a "designated
> initializer" understood. However, I have begun to use an alternate
> pattern. Before I get too far in my use of this approach, I thought it
> best to check with the more experienced developers here to see if my
> approach for doing "convenience" initializations is viable or
> potentially problematic.
>
> Since there may be lots of variations on initialization, I reverse the
> pattern and have convenience initializers all call a common -init
>
> - (id) init
> {
> self = [super init];
> // init ivars and whatnot....
> return self;
> }
>
> Convenience initializers for properties of the class invoke this common
> -init, and then make adjustments:
>
> - (id) initWithProperty:(PropertyClass*)propertyValue
> {
> if (self = [self init]) {
> [self setProperty:propertyValue];
> }
> return self;
> }
>
> Of course, my invoking code could achieve the same ends with two lines
> of code:
>
> SomeClass *instance = [[SomeClass aloc] init];
> [instance setProperty:propertyValue];
>
> As I said, my pattern is just a convenience:
>
> SomeClass *instance = [[SomeClass aloc]
> initWithProperty:propertyValue];
>
> So, I guess I have two questions here:
>
> 1) Is the convenience approach obfuscating (i.e., are the two lines of
> code clearer to others who come in to work on the source)?
>
> 2) is my way of handling these convenience initializations viable?
>
> Thanks.
>
>
>
>
>
>
>
> _______________________________________________
>
> 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