Hello, I am deveolping a plugin (or better call it a framework) and I don't want to extend JavaPlugin to my main class (or to any other class ) My problem is that my framework is something really different and calls like "this.getDatabase()" shouldn't be allowed (because I want to write my own methods and users may get confused which methods are mine and which are Bukkit's) So my question is : Is there a way to initialise a plugin without extending JavaPlugin or (if this not work) is there a way to extend JavaPlugin but not extend most of the useless methods (for example the onEnable-Method is useful with the getDatabase() isn't) Thanks
You must have your main class extending JavaPlugin. But you can make your "Framework class" containing and accessing to the methods you want it to have (from the main class)
Yeah, @FisheyLP, but also there is way to create instance in main class.. private static NameOfMainClass instance; public static getInstance(){return instance;} And in onEnable instance = this; In other classes you can do NameOfMainClass.getInstance().getDatabase()..
@bohafr That is just an abuse of static. Please don't do that. Use constructors instead. @KTB Make it a standalone ( so build it without even looking at Bukkit ) and you should be fine. http://bukkit.org/threads/tutorial-use-external-library-s-with-your-plugin.103781/
Code:java public class MyClass { public MyClass getInstance() { return this; } } Code:java MyClass c = new MyClass();c.getInstance().getInstance().getInstance().getInstance().getInstance().getInstance().getInstance().getInstance().getInstance().getInstance().getInstance().getInstance().getInstance().getInstance().getInstance().getInstance().getInstance().getInstance().getInstance().getInstance().getInstance().getInstance().getInstance().getInstance().getInstance().getInstance().getInstance().getInstance().getInstance().getInstance().getInstance().getInstance().getInstance().getInstance().getInstance().getInstance().getInstance().getInstance().getInstance().getInstance().getInstance().getInstance().getInstance().getInstance().getInstance().getInstance().getInstance().getInstance().getInstance().getInstance().getInstance().getInstance().getInstance().getInstance().getInstance().getInstance().getInstance().getInstance().getInstance().getInstance().getInstance().getInstance().getInstance().getInstance().getInstance().getInstance().getInstance().getInstance().getInstance().getInstance().getInstance().getInstance().getInstance().getInstance().getInstance().getInstance().getInstance().getInstance().getInstance().getInstance().getInstance().toString();c.toString();
@TheGamesHawk2001 It would not make sense to have a getInstance method which returns the main class instance, if you need the main class instance to invoke the method.
Please, explain to me how creating a Singleton is abusing static? It's a perfectly valid use of static, although it's not particularly good OOP. Also, see 1Rogue's post.
@Gater12 @1Rogue Code: public void passInstance(SomeObject s) { passInstance(s.getInstance()); } That's the point
@teej107 Why would you? As far as I know, the only time the Singleton is out of scope is when the class is no longer needed, at which point the JVM destroys the entire class, including its static fields. If the server reloads, the variable is reassigned in onEnable()
Idk. I never used the singleton way for accessing the JavaPlugin. I've only heard nasty things for not nullifying the JavaPlugin field but you do make a good point. Maybe I got mixed up with static Player Collections which is terrible as well.
Code: public class Main extends JavaPlugin { public static Main instance; private Framework f; public void onEnable() { instance = this; f = new Framework(); f.onEnable(); } public void onDisable() { instance = null; f.onDisable(); } } Code: public class Framework { private Main m = Main.instance; public void onEnable() { } public void onDisable() { } public FileConfiguration getConfig() { return m.getConfig(); } public void doStuff() { m.doStuff(); } }
@TheGamesHawk2001 There is a good case to be made for using Singletons, especially when it starts becoming unwieldy to pass references around that much.