getting main class plugin without static

Discussion in 'Spigot Plugin Development' started by DaanSander, May 12, 2015.

  1. Hello is there aw way to get the main class without static i already tried to create a instance of the main class but then i get a nullpointer

    sorry for bad enlgish
     
  2. Pass it through a constructor with "this".
     
  3. It's okay to have a static "instance" variable at the top of your class. Just leave it unset and set it to "this" (without quotes) in onEnable.
     
  4. Expanding on XlordalX's point, when you init the class by typing new ClassName(), in the arguments for that you can pass the plugin instance through the arguments.

    Yes it's okay, but really in most plugins it's not necessary, and often makes room for a couple issues.
     
  5. Do this for your Main class in onEnable():

    new SomeOtherClass(this);

    In SomeOtherClass:

    Plugin plugin = null;

    SomeOtherClass(Plugin pl)
    {
    plugin = pl;
    }

    Hope I helped!
     
  6. Sure, it's fine, aside the bad habits and all:
     
    • Like Like x 1
    • Agree Agree x 1
  7. Welp, you learn something new everyday.
     
  8. Ignore the politics and use static. It's the right solution for the need.
     
    • Funny Funny x 1
  9. I like how you simple they "they're wrong" when you don't have any arguments but the other side does...
     
    • Agree Agree x 1
  10. Because it's a matter of opinion and not fact and not worth debating over.

    It's a Minecraft Plugin, it has a very direct use and ANY code referencing your Plugin Object is not usable outside of the scope of A Bukkit Ecosystem, so theres no argument for re-usability.

    And for unit testing, setting static variables is very simple so that argument is invalid. The static argument for unit testing comes at the sake of static METHODS, which is actually possible to mock even: https://code.google.com/p/powermock/

    Also I never said they are wrong, I said ignore the politics. Different statements :)

    Using a singleton access pattern to access your plugin instance is not going to cause you bugs unless you do something reallllly weird.

    And it will save you lots of time in development not worrying about passing the instance around.
     
    • Agree Agree x 3
    • Like Like x 1
  11. Last time I checked there were actually pretty strong, leading ideas regarding the use of certain design patterns
    Invalid argument in the given context. Software is still software, and should be written properly.
    I think you failed to understand that it still creates tight coupling, which means I cannot test the classes which depend on the main class without (fully) testing and implementing the main class. Not quite as unit as unit should be.
    Doesn't mean it should be used freely just because it looks fancy. Singleton patterns should not be used when better alternatives (see: dependency injection) are available.
    I don't even. I... just don't.
     
    • Like Like x 2
  12. As I said, it's a matter of opinion. I disagree that DI is a better alternative than a singleton pattern for the sake of getting a plugin instance to be used in listener registration.

    It's not solving some bug
    It's not saving you time
    It's not improving code readability (registerListener(MyPlugin.getInstance(), listener); is pretty intuitive)
    It's not saving you memory

    What it does provide is pleasing politics.
    So back to my statement: ignore the politics.
    And "Get Shit Done" (tm)

    I have yet to see a case of DI style plugin instance references providing a real productivity benefit over singleton access pattern.
    I have yet to see a case where a singleton access pattern for plugin instance references actually caused a problem.
     
    • Like Like x 1
    • Agree Agree x 1
  13. * And let me clarify that I am fully aware of the original points made and agree that static CAN and OFTEN is used incorrectly.
    However I oppose the blanket idea that you should never use static, where the MC Dev community loves to shame perfectly valid cases for it, just because static has a bad rep.
     
    • Agree Agree x 5
  14. Going off this, most people that say don't use it because they simply don't know it's application or how to use it correctly. I rarely used it in Minecraft plugins but in other programs I have written it is a necessity in a sense.
     
    #14 are0planes, May 12, 2015
    Last edited: May 12, 2015
  15. It's only violating... O yes, a couple of OO design principles. Just when we happen to be writing in an OO language.
    It provides structure rather than messy, unmanageable code. "Get shit done properly" (tm).
    "this.plugin" vs "Main.getInstance()". If you so desire to match amount of characters typed.
    Try writing modular code, where I can plug in any plugin instance I want (a possible use case is where I provide an API which can be managed from another plugin).

    Have some more static hate, btw. I personally don't mind static. I mind abusing static for access and 'productivity' reasons.

    You are currently serving the opposite of your actual goal. You are trying to light the blanket on fire, instead of giving me actual reasons to use static.

    An actual good example of static is application loggers (see Logger.getLogger(), for example)

    [EDIT] forgot the double post, including that as well.
     
  16. Sure, your opinion versus that of, say, the general community and language architects of java.

    http://googletesting.blogspot.com/2008/11/clean-code-talks-global-state-and.html
    http://www.drdobbs.com/once-is-not-enough/184401625
    http://www.javawebdevelop.com/1503676/

    Not to mention, the implementation of which you use the plugin class as a singleton is grossly unsafe, versus using an enum:

    http://keaplogik.blogspot.com/2013/12/the-java-enum-singleton-pattern.html
    (Couldn't find the other article but read up Joshua Bloch's commentary about the usage)

    By definition, a singleton should only have a single instance throughout the runtime of your code. Let's point out all the problems of a basic JavaPlugin singleton:

    Code (Text):
    public class MyPlugin extends JavaPlugin {

        private static MyPlugin instance; //Unable to use "final" or any language-level guaruntees of one instance

        public MyPlugin() {} //This is the BIG issue, your class instance is constructed via an external API. You do not control the instance

        public void onEnable() {
            instance = this; //cool, so what happens when I do something like this?:
            MyPlugin.instance = new MyPlugin(); //whoops I just broke everything ever
            //Bukkit's internal checks aside, it is possible to instantiate multiple plugin objects
        }

        public static MyPlugin getInstance() { //What if this is called before onEnable?
            return MyPlugin.instance;
        }

    }
    Of course you could use a Holder pattern here but again it leads to all the same issues.

    Look, I get it, in some cases having a static getter for your main class can be useful and even simplify some code. The point of it being a problem is when you always rely on it for your code. If you're new to java (as MANY people on this forum are), then you should not use a feature of the language like static before fully understanding how it works and what it does. Saying "use static" for problems that are solved in a cleaner manner otherwise isn't just lazy, it's detrimental to other people's learning of the language.

    Static is introduced as a tool for memory management, yet it's misuse often leads to the exact opposite.