Re: Cocoa coding style (was Re: Did I reinvent the wheel?)
Re: Cocoa coding style (was Re: Did I reinvent the wheel?)
- Subject: Re: Cocoa coding style (was Re: Did I reinvent the wheel?)
- From: "Michael Ash" <email@hidden>
- Date: Sat, 10 May 2008 23:12:49 -0400
On Sat, May 10, 2008 at 10:14 PM, Jim Correia <email@hidden> wrote:
> On May 10, 2008, at 1:43 AM, Chris Hanson wrote:
>
>> In general terms though, I'll still state that it's a bad idea to enforce
>> that an object be a singleton — especially if you're new to the framework
>> and memory management rules etc.
>>
>> Rather, I'd treat being a singleton as a code smell, and try to ask
>> whether methods on the singleton instance should be class methods, or
>> whether a "shared" singleton would be useful while leaving room for specific
>> instances in the future (and specific instances to use during unit testing).
>> For one thing, enforced singletons are hard to subclass and substitute;
>> being able to do so is quite useful in certain circumstances.
>
> In many cases, enforcing the singleton-ness of an object is unecessary.
> Convention + shared instance are often good enough.
>
> I have written a couple of bona-fide, enforced singletons over the course of
> time though. These are typically objects I want to instantiate in a nib so
> that I can easily use target/action (or other IB features) with the object.
> In this case, enforcing that only one ever exist is necessary.
Even in this case, all you need to do is override -init to return the
shared object. Apple's sample code, showing overrides to -retain,
-release, and other such methods, just serves to hide bugs in the
calling code.
Mike
_______________________________________________
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