Botre Posted April 24, 2015 Share Posted April 24, 2015 (edited) Prevents inconsistencies. But can be a victim to deserialization (you can serialize without needing to implement serializable by declaring readObject and writeObject methods) and instantiation through reflection. Not to mention, public enum Singleton { INSTANCE; } Is a lot let verbose I have that one too in my lib :x Have never used it because I'm not very aware about the architecture of enums. A couple of questions: - Using the enum implementation, is there any scenario you would lose out on inheritance capabilities ? I'm almost certain the answer is no considering the very nature of the singleton pattern but I'm still curious - Are enum singeltons lazy or eager ? I'd say lazy but I'd still like to be certain (edit don't mind the underscores in my packaging :x) Edited April 24, 2015 by Botre Quote Link to comment Share on other sites More sharing options...
fixthissite Posted April 24, 2015 Share Posted April 24, 2015 (edited) I have that one too in my lib :x Have never used it because I'm not very aware about the architecture of enums. A couple of questions: - Using the enum implementation, is there any scenario you would lose out on inheritance capabilities ? I'm almost certain the answer is no considering the very nature of the singleton pattern but I'm still curious - Are enum singeltons lazy or eager ? I'd say lazy but I'd still like to be certain (edit don't mind the underscores in my packaging :x) Although Singleton pattern doesn't support inheritance, the Multiton pattern does. Only a few minor losses I can think of: - The ability to add a contract to a specific multiton value is no longer there; all multiton values must abide by the same contract. - The enum may get a bit bulky depending on what you're doing // Multiton public enum State { WALK_TO_BANK { @Override public void process(Script script) { } }, BANK { @Override public void process(Script script) { } }; public void process(Script script) { } Enum values are eagerly initialized (all multiton values are created as soon as the enum is loaded) Edited April 24, 2015 by fixthissite Quote Link to comment Share on other sites More sharing options...
Botre Posted April 24, 2015 Share Posted April 24, 2015 Although Singleton pattern doesn't support inheritance, the Multiton pattern does. Only a few minor losses I can think of: - The ability to add a contract to a specific multiton value is no longer there; all multiton values must abide by the same contract. - The enum may get a bit bulky depending on what you're doing // Multiton public enum State { WALK_TO_BANK { @Override public void process(Script script) { } }, BANK { @Override public void process(Script script) { } }; public void process(Script script) { } Enum values are eagerly initialized (all multiton values are created as soon as the enum is loaded) You're a goldmine 1 Quote Link to comment Share on other sites More sharing options...
FrostBug Posted April 25, 2015 Share Posted April 25, 2015 I won't even bother reading this entire thread :E There's no need to use enums, no need to worry about threading (he's getting the instance in onStart), no need to worry about invokelater vs. invokeandwait Literally all you've forgotten is to lazily initialize the instance in your getInstance method eg. public static GUI getInstance() { if(_instance == null) { _instance = new GUI(); } return _instance; } Quote Link to comment Share on other sites More sharing options...
fixthissite Posted April 26, 2015 Share Posted April 26, 2015 (edited) I won't even bother reading this entire thread :E There's no need to use enums, no need to worry about threading (he's getting the instance in onStart), no need to worry about invokelater vs. invokeandwait Literally all you've forgotten is to lazily initialize the instance in your getInstance method eg. I suggested an easier alternative. Although you might not need to worry about threading issues for scripts (kinda makes me assume scripts are somewhat primitive), it's a lot less verbose to do it right ;) Lazily initialization for singletons is a strongly flawed design, as there should be no reason to lazily initialize a singleton. The only reason you'd lazily initialize is if you were to call other static members from that class, which wouldn't make much sense single you have a singleton right there.Always good to learn Edited April 26, 2015 by fixthissite Quote Link to comment Share on other sites More sharing options...