Re: static vs non-static. Recommendation needed.
Re: static vs non-static. Recommendation needed.
- Subject: Re: static vs non-static. Recommendation needed.
- From: Dave Keck <email@hidden>
- Date: Sun, 12 Apr 2009 23:33:05 -1000
> Is it all right to init an object just to dealloc it in the next line (or
> create an autorelease object using a convenience method for that matter)? I
> mean, if i made it non-static, i would have something like this in the class
> that uses it:
>
> DatabaseCreator *dbc = [DatabaseCreator creatorWithDBInfo: dbInfo];
> sqlite3* database = [dbc database]; // and dbc would no longer be used.
>
> Or is it better to put up with the inconveniences of having that thing
> static?
In general, there's no good or bad way to do such things, it really
depends on context. Your instantiation method that you mentioned is
fine - but personally, I would go the static route for this situation
because, conceptually, there's no reason to instantiate a database
creator, as you mentioned.
One solution to help alleviate the hassle of passing 10 different
variables between your DatabaseCreator's class methods is to create a
struct that wraps all your variables that you're sending from class
method to class method, and simply pass a pointer to the struct
between them. This solution is simple and clean. There's no need to
expose this struct in your public interface, of course, as you can
just deal with it internally by declaring it in your .m file.
Another solution is to create static variables within
DatabaseCreator.m. I can't say I like this way of doing things, but I
suppose it's a solution nonetheless. (If you're not familiar with
static variables, check 'em out on Google.) Each helper method inside
your DatabaseCreator class would simply use the static variables
declared in the .m file to get the job done.
David
_______________________________________________
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