Well can I (just like NSApplication): 1) In supercalss, define the shared instance as id 2) In superclass, return the shared instance as id or instancetype 3) In superclass, DO NOT set up yet. 4) In superclass, set up in the method asking for the shared instance, which always use [[self alloc] init]?
在 2013-6-7，下午4:38，David Chisnall <[email protected]> 写道： > On 7 Jun 2013, at 09:30, "Graham Lee" <[email protected]> wrote: > >> Should this be wrapped in if(self == [Singleton class])? I've seen that used >> to guard against this +initialize being called multiple times when a >> subclass is used that doesn't override the method. > > Good catch. The answer is... maybe. Typically, singletons don't support > subclassing, because the semantics are a bit interesting. It's often better, > if you have a singleton that may want extending, to provide some delegate > mechanism. Or, alternatively, a way of setting the singleton instance to use. > > If you expect subclasses, then you need to be a bit more clever to ensure > that everything that tries to access the object gets the subclass version. > Traditionally, you'd do that by adding a category on the superclass that > replaced +sharedInstance with a call to your replacement. If two different > libraries try to do this, however, the behaviour is undefined. > > David > > -- Sent from my Apple II > _______________________________________________ Gnustep-dev mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnustep-dev
