Guys, thanks for your quick replies.
OK Pedro, that's a neat trick. So effectively you're using Inner to act as a "Singleton wrapper"? Which means that Inner can get access to Outer's members, although Singleton itself still can't (unless you use x to get values from Outer then mail them across to Singleton using a getXXX() method?). Hmm, so are there still a couple of issues:
i) for every Singleton I now have to create 2 classes - 1 original stand-alone (Singleton) and a "wrapper" (Inner) buried within the ultimate parent (Outer)? That doesn't seem ideal but, agreed, it does work;
ii) to keep as much encapsulation as possible, let's say I want to put lots of state-based methods in Singleton, which in turn need to set/un-set GUI components within Outer. As Singleton is outside the scope of Outer, it still doesn't have access to Outer's members. In this case, would you need to add all of the relevant GUI-changing methods to Inner instead? If that's so, have you then defeated the point of having a Singleton in the first place? Although your Singleton is a genuine Singleton, Inner is not.
So thanks for the solution, it's really interesting. Any further thoughts on these secondary issues would definitely be welcome
Thanks Mike. I reckon you and Pedro are both right - these are merely different solutions to achieving a Singleton. Yours is definitely more appropriate when you want to instantiate your Singleton up-front (say during initialisation while the user's looking at a dazzling splash screen
), while Pedro's is more appropriate when you want to use "lazy instantiation"...that means you want your Singleton built on a "Just in Time" basis, the first time that getInstance() is called, and not a moment sooner. That can be useful if say you've got 10 million potential Singleton Objects, of which you'll probably only ever need 50 during a typical program run, but you don't know which ones you'll need in advance.