Singleton or static..

Discussion in 'Spigot Plugin Development' started by Creeoer, Jul 2, 2015.

  1. Creeoer

    Supporter

    I know there is already some documented on this but for some odd reason a spigot thread somehow makes me feel more satisfied..anyway let's say I have a playermanager class which has two methods, addToGame and removeFromGame, all these methods do is add you to a player inventory hashmap then clears your inventory and removeFromGame restores your inventory from the hashmap and deletes the entry. Is it better practice to A. Make a static field for the hashmap and make both of the methods static. or B. Treat the hashmap as an instance variable and treat the class as singleton?
     
  2. In this situation I'd say it is personal preference... In other situations like Listeners, Commands and plugins they can't be static methods because an instance needs to be created for them to work as intended.

    I don't know why but for cooldowns and other things like this, I've used a class similar to the following. It works really well and is a mixture of both static (allowing the class to be accessed wherever) and singleton (Allowing storage of the instance). I think I'd use a similar class in your case.
    That class isn't finished.
     
    • Agree Agree x 2
    • Informative Informative x 1
  3. I would make the hashmap private and keep a private PlayerManager field in the main class, then pass that PlayerManager instance to other classes through their constructors.
     
    • Funny Funny x 1
  4. Creeoer

    Supporter

    That seems unnecessary, if anything just create a way to get the singleton instance and just invoke it whenever necessary. Maybe not even create an instance of the PlayerManager unless called, so that you don't have unneeded instances crowding your plugin.
     
  5. It's not unnecessary. Using an instance of your PlayerManager (or any class) that you then pass around to other classes makes it more clear how the code will interact. As your code grows, it will be easier to extend the functionality (i.e. add a new subclass that provides more functionality). This can increase the maintainability of the program, as things won't break every time you make a change. Passing your dependencies also allows things like unit testing to work, which would be difficult if a singleton was used. Here is some good discussion about why singletons are discouraged: http://www.object-oriented-security.org/lets-argue/singletons#TOC-Arguments-against-Singletons
     
    • Agree Agree x 4
  6. Recolance

    Supporter

    Everything static. Everything always static. Static is love. Static is life. #Static4President2k15
     
    • Funny Funny x 8
    • Optimistic Optimistic x 1
  7. No no. Nooo. NO. NO!

    *sigh*
    [​IMG]
    plugin doesn't get nulled, config doesn't get nulled, connection gets closed but not nulled.
     
    #7 _Cory_, Jul 3, 2015
    Last edited: Jul 3, 2015
    • Agree Agree x 5
  8. Recolance

    Supporter


    [​IMG]
    Oopsies​
     
    • Funny Funny x 4
    • Optimistic Optimistic x 2
    • Like Like x 1
  9. Creeoer

    Supporter

    So I'm guessing that if my class constructors are bloated with single class instances I'm putting too much work in a single class?
     
  10. Singleton or static? The answer to that would be a resounding no.....all jokes aside, though, in your case I don't see a reason to use either of those over normal object architecture. All they would do in your case would be to make your code a lot less flexible.
     
  11. Creeoer

    Supporter

    I'm trying to keep only one instance of a class that can be accessed anywhere, so dependency injection?
     
  12. Dependency injection indeed. It's the way it should be done. Works right off the bat if you decide to subclass it in the future, too.
     
  13. To solve a lot of constructor parameters, make your constructor private and provide a Builder object: https://en.wikipedia.org/wiki/Builder_pattern
     
  14. In what... sense? There's no sense about it, it's a design pattern.
     
  15. sothatsit

    Patron

    Singletons can be subclassed. Just change the instance of the class to an instance of the sub class.

    E.g.
    Code (Text):
    class Single {
        private static Single instance;

        protected Single() {
            if(instance != null) {
                throw new RuntimeException("instance already set");
            }

            instance = this;
        }

        public static Single getInstance() {
            return (instance == null ? new Single() : instance);
        }
    }
     
    Code (Text):

    class Double extends Single {

        protected Double() {
            super();
        }

        public static Double setInstance() {
            return new Double();
        }

    }
    Then, in your onEnable
    Code (Text):
    Double.setInstance();
    Granted, it's far from the perfect solution, but its completely valid.