getInstance() or constructor?

Discussion in 'Plugin Development' started by XLordalX, Jul 20, 2014.

Thread Status:
Not open for further replies.
  1. Offline

    XLordalX

    Hello guys,

    What would be the best to use to get an instance of the main class, a static getInstance() method in the main class or a constructor in the class where I want the instance with the main class as paramater?
     
  2. Offline

    BajanAmerican

    I personally use .getInstance() because it all resolves around the main class without any hassle. Just call up the main class and you are set - no need to keep making new constructors.
     
  3. Offline

    Dragonphase

    XLordalX

    Try to avoid using a static in situations like this. Where possible, pass your main class to the constructor of your other class(es).
     
    Garris0n likes this.
  4. Offline

    XLordalX

    Could you tell us why?
     
  5. Dragonphase You should give this thread a read, it has some informative posts.
     
  6. Offline

    Dragonphase

  7. Offline

    xize

    theres nothing wrong using static aslong you limit the usage and only to use it as a singleton or more like as abstract ways to access it (I ment with this the whole class rather than every field static so no ArrayLists and HashMaps etc just the class as an singleton) the problem with static is that beginners most of the time use it as per only option which is wrong because that would create a massive piece of dreaded and buggy code because they use static on every field to..., and most of the time only on ArrayLists and that such of objects which is actually not the way how static is used in my opinion I more call that abuse rather than using factory logic.

    since the plugin instance is the main class of your plugin, I would say its a good idea, because when using a constructor over 100 classes it kinda feels more messy than I would have with static, although I would encourage to use a constructor if you are working on smaller plugins, its just not good to use static on fields.

    but with static are some downsides to for example iteration and modifying things between alot more anonymous classes at once, this is asking for troubles, like you made a socket and you are storing elements and deleting of the list of visitors in your static List this would dramaticly fail if people visit your socket at the same time, of course there are tricks to work around but this is just a example, why you should use singleton aproaches and why absolutely not, in this case its not recommend.

    so this is bad:

    Code:
    public class test {
         public static ArrayList<Player> players = new ArrayList<Player>(); //fields are bad to be singleton, because this is absolutely anonymous and not referenced to the class
    }
    
    this is a bit better(note do this only if there is no other reasoning, you still want to have things singleton and there is NO other way, you see this approuch demostrates that static is not a solution to 'fix' arraylists and such as this shows the issue in more depth.)

    Code:
     
    public class Main {
    //or just do it with the plugin instance and remove the static keyword here.
    //that means it would be something like Main.getPlugin().getTest(); then you already limited alot of singletons.
    //if you could use final please use it because that would garantue abstraction, could be done in combination of constructors fyi.
          private static Test test;
     
          public void onEnable() {
                 this.test = test; //bam straight on top, else you see where we going to the time with NPE's
          }
     
         public static Test getTest() {
                return test;
         }
    }
     
    public class Test {
        private ArrayList<String> players;  //non static :D
     
        public ArrayList<String> getPlayers() {
            if(!(players instanceof ArrayList)) {
                  this.players = new ArrayList<String>();
            }
            return players;
        }
    }
    
    the bests way:
    Code:
    public class Main {
         private Test test;
     
         public void onEnable() {
                this.test = new Test(this); //this kinda works like a singleton but we don't use global states, this means we never ever reinstance the same instance again which means the arraylist is still the same, we just reuse the same instance, this could work in combination of a static plugin instance if you would want a global way to access it.
         }
    }
     
    public class Test {
         
         private final Main main;
         private final ArrayList<String> players;
         
         public Test(Main main) {
               this.main = main;
               this.players = new ArrayList<String>();
         }
     
         public ArrayList<String> getPlayers() {
             return players;
        }
    }
    
    maybe the third example is a bit awkward and wonky though, but it comes down to: you don't need to have a whole intherence being static you can just make for example a Manager object being static and all methods underlying in the Manager class non static also for ArrayLists and HashMaps, from there you could make a pretty good intherence of calls like bla.hi().lol().ha().containsKey("bla") while only hi() is static that means you can decrease lots of statics already.

    I hope it helps a bit, although due the extreme heat I explain things wonky:p
     
  8. Offline

    Traks

    xize
    I would say the biggest issue with 'beginners' using statics, is that they abuse it. Statics violate (in my opinion) the whole idea behind object orientated programming, which is the sole purpose of Java, as there is no need for objects when using statics. The only justified use of statics, I know, would be for initial access to some sort of API. Edit: and constants of course!

    Utilising statics over object passing through constructors also results in a more interdependent class system. There is no way external parties can modify the used instance of a certain class when certain code uses static methods. (e.g. a Listener class) You should avoid so-called 'God classes', which handle too much or contain too much data. Additionally, how exactly is object passing messy?

    Furthermore, referencing objects statically could also precipitate memory leaks, due to the developer not dereferencing these objects. This will also cause for more objects being stored in the 'old generation' of the heap, which is much less efficient than the 'young generation'. (GC iterates over it less often)

    So I would suggest only using statics when utterly necessary or providing initial access for third parties. Internal code should, in my opinion, never use statics.

    Note: most of this post is subjective
     
  9. Offline

    teej107

    If your using static only for the sole purpose so you can access it everywhere, you are using it wrong. There are a few exceptions but for beginners, you want to stay away that behavior and look up how to pass information through parameters. If you can pass the object in a constructor, it is better to do that instead. I only use static when I am needing an non-new instance that is outside of the project I am using instead of creating a brand new instance. I also use it for constants and very specific information that needs to be passed through a parameter that will decide what will be done depending on the info passed through. A lot of javax.swing (Java GUI) classes use this method.
     
  10. Offline

    xize

    Traks

    I agree with your points to, its better only to use it as api calls, because static classes wouldn't be gced unless the Classloader is marked to be collected that means probably in onDisable it may unloads it but maybe not, but anyways that could cause alot of problems to.
     
Thread Status:
Not open for further replies.

Share This Page