Might be different with everyone (personal preference), but what’s the best package structure when creating a plugin?
Mine looks something like this:
com.name.myplugin //main logical stuff
com.name.myplugin.commands //commands
com.name.myplugin.commands.admin //admin commands
com.name.myplugin.utils //collection of reusable methods
I feel like I might be missing something.
A general pattern I use is that if there are many of a specific thing (such as commands), I put them all in one class if there are a few of them (e.g. Commands.class), but if there are a lot, then I would group them by purpose under a package (e.g. RankCommands.class, ItemCommands.class). For very small plugins, which most of mine are, everything except DataManipulators gets dropped into the main class.
1 Like
My other question is, say you’re building a large plugin. If you’re making a certain features (like custom spawn messages, death messages etc). Would you cram all the logic into the main class or would you make a separate class for them (like spawnmessages.java)? I’m not sure if there’s some kind of unspoken java convention.
Thank you for your post.
Unless your name is also registered with a TLD, there’s no point in using com
in your package. The parent package is supposed to be an identifier for the creator - normally a website to view other work, or a company.
For instance, I own the domain ferusgrim.com
, so I could use com.ferusgrim
. Otherwise, there’s no point.
Some people use GitHub’s static delivery for a package identifier.
io.github.ghusername
Typically you see: {identifier}.{artifactId}
As far as splitting logic up into other classes, it’s general convention to keep Objects as separate as possible, while maintaining simple logic into a single class.
For instance, if your command is simple, you may want to create an anonymous class to dictate your command’s logic.
If your command is more complicated and requires contacting other Objects, storing information, etc, you’re almost always going to want it to be its own Object.
2 Likes
flavor.pie
ftw
Also, there’s next to no point using an anonymous class when you could use a lambda or a ref.
1 Like