Static instance of JavaPlugin?

Discussion in 'Plugin Development' started by jackwilsdon, Jul 19, 2013.

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

    jackwilsdon

    Is using a static instance of JavaPlugin bad practice? I am wondering what difference in speed and stability the two following snippets offer;
    Code:java
    1. class Plugin extends JavaPlugin {
    2. public static Plugin plugin = null;
    3.  
    4. public void onEnable()
    5. {
    6. this.plugin = this;
    7. }
    8. }
    And to use it I would simply do Plugin.plugin.
    The alternative is to pass an instance of Plugin to whatever needs it, like this;
    Code:java
    1. // Inside Plugin.class
    2. ExampleClass example = new ExampleClass(this);
    And simply have the constructor accept it, and set a private variable to contain the instance.
    My question is simple, which is better, and why? I've been using the constructor way of doing it for a while now, but I'm wondering how much easier it is to just have a static instance.
     
    Europia79 likes this.
  2. Offline

    Devil0s

    Of course the second way.
     
  3. Offline

    jackwilsdon

    Can I ask why you would say the second way is better?
     
  4. Offline

    desht

    It's not as clear-cut as that. There are good arguments for and against having a static plugin instance, but if you're going to use one, you should at least:
    1. Make it a private field, and get it via an accessor; better encapsulation.
    2. Set it to null in your onDisable(); good memory management.
    Arguments for using a static instance field:
    • Bukkit plugins are naturally singleton objects; it doesn't make sense to have more than one instance of your plugin, so having a static field to get it fits well.
    • It avoids having to pass the plugin instance around as a parameter to every single object that might need to use it for whatever reason, which can lead to unwieldy method signatures.
    Arguments against:
    • The singleton pattern is controversial. There's a valid argument that it's just a fancy way of doing global variables, and that is very poor OO practice.
    • Singletons make unit testing a lot more awkward.
     
    Europia79 likes this.
  5. Offline

    CubieX

    It works both ways.
    But in object oriented programming, you usually look after things like "encapsulation" and "visibility".
    Each class should only get access to fields, objects or methods the really need.

    I saw plugins here, where the author used static variables and methods all over the place.
    Simply because he had no clue how he should access those from other classes if they were not static.
    This is bad coding style.

    A good example for static methods would be common utility methods or public enumerations you would like to offer all of your classes, Because they are not class specific.

    A static plugin variable is the least of my concerns here.
    I don't like it, but I can't talk against it.
    But aside from that, making something "static" should always be backed by some good reason.
     
    MightyOne and Europia79 like this.
  6. Offline

    ZeusAllMighty11

    CubieX

    lol yeah I see that too, I laughed when i saw your post.

    Code:
    public static final ArrayList<Player>Players = new ArrayList<Player>();
    
    *lululul*[/CODE]
     
  7. Offline

    jackwilsdon

    desht, thanks for clearly explaining the reasons for and against static variables :) I think I'll stick with just passing classes what they need.
     
  8. Offline

    Janmm14

    I do it this way:
    Code:
    public static YourMainclassName get() {
        final Plugin plugin = Bukkit.getPluginManager().getPlugin("YourPluginName");
        if (plugin == null)
            return null;
        if (plugin instanceof YourMainclassName) {
            return ((YourMainclassName) plugin);
        }
        return null;
    }
     
  9. Offline

    ZeusAllMighty11

    Janmm14

    Well isn't that kind of redundant?

    You are using your own plugin to grab and see if your plugin is null, but it can only be null if it isn't there, and if it isn't there it wouldn't be checking for itself being there.

    wut
     
    Devil0s, desht and microgeek like this.
  10. Offline

    microgeek

    Use a static field, and null it when the server shuts down(or reloads).
     
  11. Offline

    1Rogue



    I think it would be simpler to just use:
    Code:
    public static MyPlugin getInstance() {
        return (MyPlugin) Bukkit.getPluginManager().getPlugin("MyPlugin");
    }
    As GreenGamer mentioned, you'd only be null if your plugin wasn't there.
     
  12. Offline

    Janmm14

    Possible. Should change that.
     
    jackwilsdon likes this.
Thread Status:
Not open for further replies.

Share This Page