Jump to content

Singleton JFrame not appearing on script start


Recommended Posts

Posted (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 wink.png

 

I have that one too in my lib :x

 

acc838905467b5cd9f994da06e6fe084.png

 

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 tongue.png

 

- Are enum singeltons lazy or eager ? I'd say lazy but I'd still like to be certain tongue.png

 

(edit don't mind the underscores in my packaging :x)

Edited by Botre
Posted (edited)

I have that one too in my lib :x

 

acc838905467b5cd9f994da06e6fe084.png

 

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 tongue.png

 

- Are enum singeltons lazy or eager ? I'd say lazy but I'd still like to be certain tongue.png

 

(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 by fixthissite
Posted

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 <3

  • Like 1
Posted

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;

}

 

Posted (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 by fixthissite

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...